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CHAPTER 1: INTRODUCTION 


With the Multisystem Network Facility (MSNF) of SNA products it is possi- 
ble to interconnect single-domain networks to more complex multi-domain 
networks. This document jis’ intended to show how aie multi-domain 
(multi-host) SNA network can be operated from a single control position. 
Within this, emphasis has been placed on the description of controlling 
remote sub-hosts from a central host. This paper describes the speciali-~ 
ties of central operation and how they are managed by means of 
Communication Network Management products. It further shows samples of 
command lists, procedures, routines etc. as a help to introduce the con- 
cept of centralized network and system operation in an installation. 
Nevertheless, many of the products and procedures described here as tools 
to manage centralized operation are applicable in every SNA environment. 


This document is one of a series of reports on Communication Network Man- 
agement (CNM). Management, as defined for these papers, is a set of tools, 
procedures and approaches used to control a network. A list of the other 
CNM documents can be found in "Appendix D. World Trade System Center 
Technical Papers" on page 75. The list shows the title and the order num- 
ber together with a short description of the content of each of the 
publications. 


The descriptions in this document are based on the following software: 


- MVS/JES2 as the operating system for 
a central host and sub-host(s) 

- ACF/VTAM Version 2 

- ACF/NCP Release 3 


The reader may adapt the descriptions to configurations containing 
MVS/JES3 systems if he considers that MVS/OCCF jis not supported in 
MVS/JES3. DOS/VSE is not mentioned here because central control of MVS - 
DOS/VSE and DOS/VSE - DOS/VSE configurations is already described in the 
document "Communication Network Management 7 Managing Interconnected Sys- 
tems', GG24-1539. 


This document jis. structured to first give an overvien on central 
operation. It then covers 


- System and network control 
~ System and network activation 
- Failure and recovery 


in three different chapters. The CNM products 


NCCF (Network Communication Control Facility) 
NCCF/TAF CTerminal Acces Facility) 

NPDA (Network Problem Determination Application) 
MVS/OCCF (Operator Communications Control Facility) 
SOF (Ssecondary Operator Facility) 

NPA (Network Pearformance Analizer) 

HCFCHost Control Facility) 

INFO/System CInformation System V2) 

Which includes INFO/MVS and INFO/Management 


are described in the last chapter. Readers who are familiar with these 
products can skip this chapter. Other readers should read it after the 
next chapter so as to understand the rest of the document. 


It is expected that the reader has reasonable knowledge about SNA network 
operation. Certain areas will be reviewed in more or less detail although 
they do not solely refer to central control of multi-host networks. This 
is done to show a more complete picture of central network and system con- 
trol rather then to provide an SNA operation education. 


Note: A translation list for the acronyms and abbreviations used through- 


out Te text can be found in "Appendix E. Acronyms and abbreviations" on 
page - 
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CHAPTER 2: CENTRALIZED NETWORK AND SYSTEM OPERATION 


The ability to consolidate the operation of multiple processors at a sin- 
gle point of control has been a requirement for several years. For local- 
ly attached processors, this requirement was recognized e.g. by the 
operating subsystem JES3 which allows an installation to manage several 
processors as a unity and to divide operator control by processor funcy 
tions rather than by processors. 


For distributed processors attached to each other via data communication 
lines, the same requirements exist together with the requirement of cen- 
tral control on the network. Tools and techniques are available to accom- 
plish central control of an SNA network and distributed hosts with today's 
hardware and software. This paper provides some information describing 
how all this works together and what constraints can be expected. Some 
topics described here may be already standard, as some installations whose 
host processors and communication controllers are locally attached to 
each other via channels have already realized centralized control of their 
network. Other facilities described, such as ROCF and MVS/OCCF, make it 
possible to bring remotely located MVS processors under central control. 


The reasons for central control of a network and distributed host process- 
ors could be e.g.: 


° Make operation, maintenance, and coordination more manageable 
e Provide better service for the end users 
° Reduce costs 


All these may apply to many installations but central control only works 
in configurations up to a certain size. For size you may consider here the 
computer power of a single location as well as the extension of the net- 
work or the distance between the locations. It would be certainly ridicu- 
lous to control a data center with several CPUs, lots of tape drives, MSS, 
IBM 3800 printers, and so on froma remote data center similarly equipped. 
Central control of a network and host processors should be treated as an 
option rather than a compulsion for multi-host networks. If large data 
centers share a common SNA network, each data center can be responsible 
ee ee of the network and may control sub-hosts, thus forming central 
control. 


On the other hand, there are no restrictions which apply to a special 
environment. The design of SNA allows central network control and it 
depends on the application of hardware and software products as to how 
much central control can be achieved and how it is facilitated. It is men- 
tioned throughout this paper where a special hardware unit or configura~ 
tion has advantages or creates additional constraints but there are no 
hardware or configuration recommendations made here. 


Before we have a look at the software products needed for central opera- 
tion of a multiple host environment, we still should have a look at two 
general types of configurations. The first one is a multi-host configura- 
tion where all host processors are at a single location and somehow chan- 
nel attached to each other; like the configuration shown in Figure 1 on 
page 4 Without the two sub-hosts at the bottom. Such an environment can 
be centrally operated by the well known standard software and even without 
NCCF. The possibilities with the powerful system message routing facili- 
ties of MVS and e.g. JES3 are numerous. It is possible to separate 
network related messages from other messages and concentrate these mes- 
sages from all hosts to a single console. 
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Figure 1. Sample of a centrally controlled configuration 
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The second type of configuration contains remote sub-hosts as in Figure 1 
on page 4 (now the complete picture). Within this configuration it is 
still possible to centrally control the network to a certain degree with 
the basic software. For example, all terminals in the network which are 
attached to an IBM 3705 can be controlled from one host. But VTAM on the 
sub-hosts is also part of the network and these remote VTAMs control 
applications and locally attached terminals and have channel attached IBM 
3705 controllers as ports to the network. VTAM on a remote sub-host has 
to be operated from the central site to fully achieve central network con- 
trol and for that the standard operating systems are not sufficient. 
Additional tools, which are in general called Communication Network Man- 
agement (CNM) products, have to be used to provide for the desired 
operability. These products are presented in the following list in an 
arbitrarily chosen classification. This is to show which products are 
mandatory to achieve a certain level of central control of a sub-host and 
which provide additional functions used to improve system and network man- 
agement. 


1. Central network operation 
NCCE provides for remote console support for VTAM. 
Messages can be received from a remote VTAM. 
Commands can be issued for a remote VTAM. 
2. Central operation of remote sub-hosts after activation 
MVS/OCCF provides for remote MVS console support beyond VTAM. 
System messages can be received from a remote MVS. 
System commands can be issued for a remote MVS. 
3. Central operation of remote sub-hosts 
ROCF is a hardware feature in the IBM $300 processor which 15 
supported by MVS/OCCF. It facilitates a remote system 
console including remote IML/IPL. 
4. Supplementary products 
NCCF/TAF is a terminal simulator program. It allows a user to logon 


to and control subsystems like CICS/VS, IMS/VS, and IBM 
8100 from an NCCF terminal. 


NPDA assists in network and system problem determination for a 
local or remote domain. 

SOF is used to simplify and automate MVS console operation. 

| Most of the SOF functions are now included in MVS/OCCF. 

NPA een and displays network performance data from an 
CP; 

HCF allows access and control of IBM 8100 subsystems from an 
IBM 4370 processor 

INFO provides support for Problem/Change/Configuration Man- 
agement. 


You may now wish to review Figure 1 on page 4 to see the location of the 
software products which are dealt with in this book. Here, MVS/JES2, 
ACF/VTAM, and ACF/NCP are the base products for central network operation 
and NCCF and MVS/OCCF are the mandatory products to control remote 
sub-~hosts. All of them must be available in every centrally operated pro- 
cessor in the network. 


One of the prerequisites for introducing central network control ina real 
environment is the definition of a network wide convention for the naming 
of network nodes. Maintenance and operation of a network can be dras~ 
tically simplified by a carefully chosen naming convention. Network names 
should be short, simple, and expressive to assist the network operator in 
his daily work. 


The planning and preparation to centrally control an SNA network and the 
ee in the network is very much installation dependent and may 
include 


e installation of the required software 
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e rearrangement of routes between subareas 
° changes in the hardware area 
e rearrangement of backup capabilities 


The introduction of central control after the general planning should then 
be a step by step approach. One of these steps can be e.g. the activation 
of a sub-host from the central site or achieving control over a single 
3705 or a single application. If the prerequisites for one step are pro- 
vided, the central control should be practiced over a certain period 
before the responsibility for the SUnIeeS of that step 1s fully handed 
over to the central site. 


Moving data around the network becomes an important task in a centrally 
operated network. A decentralized multi-site environment, where each site 
controls its own network part, can be organized so that only information 
about cross~domain resources and VTAM and NCP PATH definitions have to be 
exchanged between locations. But in a centralized network with remote 
sub-hosts, the necessity for exchanging maintenance data grows. For exam- 
ple, when an IBM 3705 1s loaded via VTAM through a sub-host's channel and 
the NCP is activated afterwards from aecentral host through a 
cross~subarea link, then the NCP definitions have to be available at both 
hosts. The maintenance of the network which consists of items like 


Keeping the members of the VTAMLST data set up to date 

Keeping the NCP load modules up to date 

Keeping VTAM exit routines, USSTABs, MODETABs, etc. up to date 
Sending VTAM and NCP dumps to the maintenance location 

Sending trace data to the maintenance location 

Applying fixes to the system components 

Keeping operator information up to date 

Collecting error records at the maintenance location 
Collecting performance records at the maintenance location 


has to be carefully considered in planning for a centrally operated net- 
work. It is however not the purpose of this paper to address this area in 
further detail. The reader should refer to the documentation of data 
transfer products like 


~ JES2/NJE and 
- Cross-Domain Network Data Transfer (CCDNDT) FDP, 
Program Number 5798-DAE 


for planning purposes. 
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CHAPTER 3: NETWORK AND SYSTEM CONTROL 


NETWORK CONTROL 


The tendency to concentrate communication network management to one point 
of control is stimulated by the fact that an active network does not need 
much operational effort as long as the network is working well. Most of 
network operations are related to recovery or problem determination. On 
the other hand, network monitoring becomes more important. To provide the 
required availability, it 18S important to quickly detect and respond to 
any abnormal situation in the network. VTAM or communication network man- 
agement tools rather than the end user should tell the operator that there 
is something wrong in the network. NPA and NPDA Version 2 have standard 
facilities to alert operators of situations deviating from normal. These 
facilities are really useful because information. of vital importance can 
be directed to the operator's attention. 


SYSTEM CONTROL 


Newly available products like MVS/OCCF make central control of remote 
hosts possible. Thus the central operator's responsibility in the scope of 
operation and monitoring can be expanded to comprise all components of the 
whole network as well as systems, subsystems, and applications. Control- 
ling sub-hosts at remote locations require additional techniques and 
tools in comparison to those required for decentralized operation where 
the system components are within the operator's reach. Products like NCCF 
and OCCF which are valuable tools in all communication network environ- 
ments become mandatory for centralized operation and monitoring. 


By concentrating operational possibilities at the central site, many 
sub-hosts may not require a data processing skilled operator at the remote 
site. It is important in order to further reduce operational requirements 
at the remote site, to transfer monitoring of a sub-host to the central 
host. Monitoring iS a permanent task to ensure that everything is alive 
and well. Care can be taken of the sub-host by people who are not dedi- 
cated to that job only if the sub-host is monitored by the central 
operator or automatically by itself. However, depending on the con- 
straints of an installation, there are still more or less operator actions 
inevitably to be done at the remote site. 


The following sections within this chapter are mainly organized by the 
tools which support the operator in his daily work: 


NC CF 


NCCF is a VTAM application program used to control an SNA network. At 
least VTAM itself, NCCF, and one NCCF display terminal have to be active 
and the network operator has to logon to NCCF as an NCCF user with the cor- 
rect password, before the network can be operated through NCCF. An NCCF 
user can logon cross-domain to an NCCF in another host from a terminal 
which is already in session with NCCF. This establishes an NCCF to NCCF 
session and allows communication with multiple NCCFs simultaneously from 
one NCCF terminal (see Figure 18 on page 45 for a sample display). 


At first sight network operation using NCCF is not very much different 
from using native MVS console support and routing all VTAM messages to a 
specific console. You can issue the same VTAM commands 


D NET,.... 
V NET,... 
POONER gies 


and you will get the same VTAM messages on your NCCF terminal as on an MVS 
system console. But NCCF 1s more. It has a variety of functions (de- 
scribed in "Network Communications Control Facility (NCCF) Release 2" on 
page 45), which provide a program base for communication network manage- 
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ment. Central operating of a multi-host environment can hardly be done 
without NCCF and products like OCCF, TAF, and INFO/System supplying capa- 
bilities beyond pure network operations. The central operator mainly uses 
NCCF and its related products to monitor and control the communication 
network and systems, subsystems, and applications at the remote site. 


Although NCCF ‘can be used right after installation, some additional effort 
is necessary to take full advantage of the capabilities offered by the 
product. This is primarily writing command lists for simplifying network 
operations and assigning PF keys to functions used most often. Further 
customization can be Hone by writing customized command processors or exit 
routines. 


NCCF's PF key assignment is static for the duration of an NCCF run and you 
have to write an exit routine to make PF key assignment to CLISTs 
possible. The implementation of the CLIST capability is more flexible. It 
is possible to add new CLISTs or modi fy existing CLISTs and use those 


CLISTsS without restarting NCCF. Here is an example of a very simple CLIST 
just to illustrate how easy operator input can be simplified. The one 


statement CLIST 
V NET,ACT,ID=&1,SCOPE=ALL 


is stored as a member called ‘ACT' into the NCCF data set with DD-name 
DSICLD. The CLIST is invoked when the NCCF operator enters for instance 


ACT L14025 
and is then executed as the VTAM command 
| V NET,ACT,ID=L14025,SCOPE=ALL 
Further CLISTs are discussed in section "CLISTs" on page 13. The reader 


may also refer to a paper called 'CNM Customizing NCCF, GG24-1554' as a 
supplement to the NCCF customization manual. 


Controlling a multi-host environment can all be done from a single NCCF 
terminal. The central CPenetor2 can 


e control the network by issuing VTAM or NCCF commands, invoking NCCF 
CLISTs or user written command processors, receiving unsolicited mes- 
sages 

° access system consoles via NCCF to OCCF sessions 

° access CICS/VS or IMS/VS as a master terminal operator via TAF 

° access IBM 8100/DPPX or IBM 8100/DPCX subsystems via TAF and HCF 

e do problem determination by NPDA 

@ = =«=©6©do problem management by INFO/Management 


° ae system and network exceptions by the NPDA Alert Dynamic Dis- 
rey 


——t is clear that a central operator in a medium-sized or large environment 
is liable to be swamped by messages trying to handle all this on only one 
screen. Separating some of the functions described above to different 
NCCF terminals could be necessary. The next figure shows a sample of a 
possible multiple NCCF console configuration. 
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NCCF 
Terminal A 


unsolicited messages issued 
by the central host's VTAM 
network changes by operator 
input 


NCCF 
Terminal B 
unsolicited messages issued 
by sub-host's VTAMs copy 
network changes by operator terminal 
input via NCCF to NCCF sessions 
controlling sub-hosts through 
NCCF to OCCF sessions 


NCCF 
Terminal C 
master terminal for CICS/VS 
and IMS/VS subsystems (via TAF) 
control of IBM 8100 sub- 
systems (via HCF and TAF) 


NCCF 
Terminal D 
- VTAM network information display 
problem determination through 
NPDA 


NCCF 
Terminal E - 


NPDA Alert Dynamic Display 


Figure 2. Multiple NCCF consoles 


To plan for a multiple NCCF console configuration for central network and 
system control you need to understand NCCF's message routing 
capabilities. You also have to take into consideration that some func- 
tions need an application to application session setup before you can use 
them and that products like NPDA and OCCF make use of NCCF to NCCF ses- 
sions. The following hints give you some information in this area: 


e Any kind of messages which respond to a terminal input are routed back 
to the terminal where the input was entered. 


e Messages generated by VTAM as a result of an unrequested change in the 
network are called unsolicited messages. VTAM deliverers them to NCCF 
as they would go to the system console when NCCF is not active. Ina 
multi-domain network they comprise messages relating to same-subarea 
and cross-subarea components depending on VTAM's ownership. NCCF 
delivers unsolicited messages to only one NCCF terminal and when they 
are scrolled off the screen they cannot be recalled. It is a problem 
to make NCCF route these messages to the terminal of your choice. You 
can find a rather complex diagram in the 'NCCF Terminal Use’ manual 
about unsolicited message routing but it does not tell you all you 
have to know. Unsolicited messages routing in NCCF is dependant on 
things like: operator authorization, sequence of terminal definition 
in NCCF, sequence of logon to NCCF, etc. In some cases for instance, 
the first operator who logs on to NCCF gets all the unsolicited mes- 
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sages. It is fairly important especially for the NCCF to NCCF sessions 
Clogon cross-domain to NCCF) that organizational arrangements are 
made for the logon sequence to make sure that unsolicited messages 
appear at the terminal you want. 


A network can be divided in a way that an NCCF operator can control a 
subset of the network resources. So, distribution of unsolicited mes- 
sages to different NCCF terminals can be achieved depending on network 
resource names. For that you have to add the SPAN parameter to all 
major and minor node definitions in VTAM and the NCP deck(s) which 
belong to such a subset. 


A NCCF operator can logon cross-domain to an NCCF on another host. He 
can do this either from a dedicated terminal or from a terminal which 
is already in session with an NCCF (this is probably the more common 
way). If the operator is in session with more than one NCCF, the mes- 
sages from different hosts are intermixed but they can be related toa 
particular host by their message prefix. For NCCF cross-domain mes- 
sage routing, the rules described earlier apply. 


Errors recorded by NPDA relate to components which are owned by the 
host where NPDA is running on. This means that in a centrally con- 
trolled multi-domain environment most errors are recorded in the data 
base of the central host and can be viewed from a terminal logged on 
same-domain to NCCF. NPDA viewing filters can provide a means of mes- 
sage routing. For instance, NPDA Alert Dynamic Displays can be set up 
for subsets of the network by specifying different sets of viewing 
filters for every NPDA Alert Dynamic Display screen (see "NPDA Version 
2" on page 16 for more information about NPDA). 


If NPDA is also available on a sub-host, errors of local hardware or 
shared ownership resources, such as NCPs, are recorded at the 
sub-hosts NPDA data base. To view such data, an NPDA to NPDA 
cross~domain session can be established from the central host. For 
NCCF multiple console configuration considerations it is noted that 
such a session uses an existing NCCF to NCCF session. 


NCCF to OCCF cross~-domain sessions can be established in two ways: 


= Logon cross-~domain to NCCF from a dedicated terminal and then 
establish a same-domain NCCF to OCCF session. 


- Use an existing NCCF to NCCF cross domain session which is proba- 
bly the more sensible way. 


TAF does not require any special multiple console considerations. TAF 
uses its own sessions to supply access to other applications. Provided 
the NCCF user has the proper authorization, TAF can be used from any 
NCCF terminal. 


MVS/OCCF 


MVS/OCCF has basically three functions which are nearly independent from 
each other: 


1. 
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Simplify system operation by CLISTs and automatic message replies. 
These facilities are independent of any communication access methods 


~ and can be used in any MVSZJES2 system. 


Allow remote operations of an MVS/JES2 system through an NCCF to NCCF 
session. This function can be used in conjunction with the facilities 
pees above and allows the monitoring and control of remote sys- 
ems. 


Support ROCF, a feature of IBM 4300 processors. ROCF allows an IBM 
4300 processor to be remote operated and IPLed by an IBM BSC 3275 ter- 
minal through a switched line. OCCF can be used to simulate the IBM 
3275 and thus make it unnecessary to install a IBM 3275 and a BSC line 
that requires Emulation Program (see section " Activation of a remote 
IBM 4300 by ROCF and MVS/OCCE" on page 26 for more information). 
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The first two facilities provide essential functions required for remote 
MVS/JES2 system operation while the third is an indispensable capability 
in running unattended remote sub-hosts. 


Remote operations of an MVS/JES2 system are achieved in OCCF by logically 
transferring the system console from one host to another. This is the key 
facility to monitor and control remote sub-hosts and its usage is simple. 
The central operator logs on through an existing NCCF to NCCF session to 
an active OCCF in a sub-host. He is than able to communicate with the MVS 
system as an MVS operator (see Figure 3, Figure 4 on page 12, and Figure 5 
on page 12). 


Yates COMMUNICATIONS CONTROL FACILITY 09/27/82 12:37:34 A 
NCF10 SDOM NCF1l 
NCF10 DSIO33I NCF11 SESSION STARTING FOR NETOP 
NCF10 PLEASE PRECEED REPLY TO PASSWORD WITH ?. 
NCF11 DSI809A PLEASE ROUTE OPID,PASSWORD,PROFILE,HARDCOPY,INITIALCMD 
NCF1l DSI810I NCCF ACF/VTAM READY 
NCF11 DSIO20I OPERATOR NETOP LOGGED ON FROM TERMINAL NCF10001 USING 
PROFILECPROFGLOB),HCL( ) 
NCF11 LOGONX 
NCFIil DSI810I NCCF ACF/VTAM READY 
NCFil DSI082I AUTOWRAP STARTED 
You have CTL=GLOBAL and MSGRECVR=YES for your session. 
Enter LOG/LOGOFF to terminate session. 
Enter HELP, PFK1 OR PFK13 FOR HELP. 
Enter NOTES for system messages. 
OCF11 %QLOGON {=== invokation of user provided CLIST which issues 
ROUTE NCF11,O0CCF %QLOGON €=== this command 
DSI810I NCCF ACF/VTAM READY 
E NCF11 STC 480 CBFO29I QLOGON ACCEPTED FOR NCCF OPERATOR NETOP 
E NCF11 STC 480 CBFO38I MVS/OCCF HAS BEEN QSTARTED FOR REPLY 


rriaotx 


% 
| 

C 
C 
C 
C 
% 


Figure 3. MVS/OCCF output on an NCCF screen: The operator logs on 
to an OCCF by routing the command 'OCCF %QLOGON' to one 
host's NCCF (CNote that *% and the character sequence OCCF 
are user chosen). He can then monitor and control the host 
from his NCCF terminal by receiving system messages, 
1ssuing commands or invoking OCCF CLISTs. System messages 
are intermixed with other NCCF output and can be related to 
eo host by the NCCF provided prefix (CNCF11 and 

i i 
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NETWORK COMMUNICATIONS CONTROL FACILITY 09/27/82 12:38:17 A 
IEE1I2~I 12.37.27 PENDING ae 769 CNCFI1 
IM=2 EM=1 RU=0 IR= AMRF | 
T MESSAGE TEXT 
r03 ADM2000 I TO TERMINATE ADMOPUT REPLY ‘STOP’ 
OHARat NCFil REPLY WITH VALID NCCF SYSTEM OPERATOR 
r01 CHFO0O11A ENTER HCF/LCV CONTROL COMMAND 
XITEAQO0O0A 410,CC=3/NO PATHS AVAILABLE,,, 
XICH505A RACF INITIALIZATION ABEND S 013. 
¥ITEA911IE COMPLETE DUMP ON SYS1.DUMP00 
FOR ASID (0001) 
ERROR ID = SEQ00001 CPU0O ASIDO001 TIME12.06.20.6 


279? XX 
ocfll da,l 


Figure 4. MVS/OCCF output in response to an operator issued 'D 
R,L*': NCCF clears the screen before it presents these 
messages 


NETWORK COMMUNICATIONS CONTROL FACILITY | , 09/27782 12:38:38 A 
IEE104I 12.38.00 82.270 ACTIVITY 773 CNCF11 
JOBS M/S TS USERS SYSAS ~ INITS ACTIVE/MAX VTAM 
00000 00008 00002 00006 00003 00002700040 
JES2 JES2 TEFPROC NSW §5 SOF. SOF SOF OWT §$ 
OCCFN OCCFN ST1 IN S NET NET NET NSW OS 
TSO TSO TCAS OWT S$ VMDISC VMDISC DISC OWT S$ 
OWT S$ ADMPRINT ADMPRINT ADMPRINT OWT 5S 


HCF HCF $T1 
TSOUSR1 OWT TSOUSR2 OWT 


Figure 5. MVS/OCCF output in response to an operator issued 'D 
A,L': NCCF clears the screen before it presents these 
messages 


The central operator may do this from the same or another NCCF terminal 
for all sub-hosts in the network as it is shown in Figure 6 on page 13. A 
logon to OCCF in the same domain is also possible and may be sensible. 
This allows e.g. a central operator to invoke OCCF CLISTs for the central 
host from his NCCF terminal. 
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) 


) 


Central host operators 


Sub- 
OCCF/NCCF VTAM | peerancer host 
console ROSS Sena ye 1 
% 
Sub- 
| VTAM | DECC CRON: | host 
OCCF/NCCF ee ei ee re Seis 2 
console 
¥ . 

Sub- 
| | VTAM | ECE an Gee host 
Central Re aS ee ee 3 
host 

ee ei oe Se em ¥ Sub- 
| VTAM | ch a ea | Babe 
¥% enue caus Gums Geen GDR Suse CORD GOR GAWD GED Gemn GED GON COU Gis) OUND GOED Gub WEED Gams Guy GND GEE) CED Gane OUND GEl GEE GID USED Ui RD UD Gi Uae GED cam CUD GHD CED WED US GHD GED OD GID OED Ge Cun 


Figure 6. Multiple sub-hosts controlled through OCCF 


The user can define the messages to be routed to the OCCF/NCCF terminal. 
Messages can be selected by their MVS routing code and by the message id. 
E.g. by specifying 


IEAX ROUTE 


in the OCCF definition deck of a sub-host, all messages starting with the 
characters IEA are routed to a logged on OCCF/NCCF terminal. Message rout~ 
ing tn OCCF has no influence on the message routing in MVS. All messages 
which go to an OCCF/NCCF terminal are also processed by the console sup- 
port of MVS. However, multiple consoles are not supported by OCCF. One 
host can only have one OCCF console. 


CLISTS 


NCCF, OCCF, and SOF command lists can be used to speed up and simplify 
network and system operation. A CLIST allows a list of commands to be 
invoked for execution by one command. NCCF supports CLISTsS consisting of 
VTAM commands, NCCF commands, NCCF control statements and statements to 
invoke other NCCF CLISTs. NCCF has the most powerful CLIST control lan- 
guage of the three products. The CLIST support of OCCF and SOF are fairly 
similar to each other. OCCF/SOF CLISTsS can contain OCCF/SOF control 
statements and everything that can be entered through a MVS system 
console, e.g. MVS and JES2 commands. 
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The following chart gives an overview to see which type console must be. 


used to invoke a specific type of CLIST or to issue a specific type of com- 
mand (MVS, JES2, or VTAM): | 


7 NCCF terminal 
MVS console NCCF terminal logged on to OCCF 


MVS and JES2 


commands + 
VTAM commands + 
NCCF CLISTs + 
OCCF CLISTs + 
SOF CLISTs + 
+ possible 
= not possible 
x possible by an installation coded NCCF command processor. The 


source statements for such a command processor called 'MVS' are con- 
tained in this book and can be found in “Appendix C. NCCF command 
processor: MVS™ on page 69. '‘'MVS' allows a user to issue MVS com- 
mands, JES2 commands, invoke OCCF CLISTs etc. from an NCCF terminal 
or an NCCF CLIST. Although no messages are returned to an NCCF ter- 
minal Ce.g. when a 'D A,L‘' 1s issued) this program is still useful 
as it 1s shown in several samples later in this book. 


Note: VTAM commands include replies to soma VTAM messages. 


A central operator can be easily over run if he has to operate multiple 
systems by the standard capabilities of the operating systems. To make 
central operation efficient he has to be relieved as far as possible. For 
centralized network and system operation, CLISTsS are therefore nearly 
Indispensable. Sample CLISTs for specific problems are documented 
throughout this paper. Within this section CLISTs are treated more gener- 
ally and with the intention to show some more samples: 


Online information 


NCCF, OCCF, and SOF do not have any online ‘Help' function which provides 
information for the users about usage and function of the operating facil- 
ities. This can be overcome by using the CLIST capability of each product 
to tailor its own 'Help' facility. Such a ‘Help’ facility should be pro- 
vided at least for the installation supplied CLISTs. Most of the CLIST 
samples described in this paper contain within them a little description 
of their function and how to use them. By convention, a user gets the 
"Help information if a CLIST is invoked with a ? as the first parameter 
or if no parameter is specified for a CLIST which requires one. An over- 
view on operator commands, CLISTs, etc. should be also provided to give 
oS inexperienced user an introduction (see "NCCF CLIST: HELP™ on page 


However, providing for descriptive information causes additional exertion 
in defining a CLIST and for CLISTs with just a few statements it is often 
enough information to have a look at these statements. For OCCF and SOF 
CLISTs the display facility of these products can be used to incorporate a 
*‘Help’ tool in a CLIST with just a few standard statements. If you have a 
look at "CLISTs for system monitoring™ on page 60 you can see the state- 
ment 'ZQSHOW SYSMON’ near the bottom of the CLIST SYSMON. %QSHOW is an 
OCCF command. Within this sample, it is executed when the user enters 
"SYSMON ? ' and it will display the statements of the CLIST SYSMON at the 
users console. | . 
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Note: Throughout this paper % is used to designate an OCCF command or 
CLIST. The OCCF default designator character is / 


Installation provided consistency between NCCF, OCCF, and SOF CLISTs 


The samples in "CLISTs to activate network nodes" on page 57 should show 
how one and the same function, is defined in NCCF, OCCF, and SOF. In an 
operation environment where two or all three products are installed there 
is an advantage to define e.g. an NCCF CLIST and an OCCF CLIST with the 
same external syntax for the same function. The activation of network 
nodes is just a sample for that and it provides similar capabilities for 
the operator at an MVS console and an NCCF terminal. 


Simplification of operation 


If you have a look at the CLIST shown under headline "MVS/OCCF CLIST: OS 
MOUNT command" on page 59 you can see how the 0S MOUNT command can be sim- 
plified. An operator just has to enter e.g. 


“2M 197 DLIB8&2 instead of 


V 197,ONLINE 
M 197,VOL=(SL,DLIB82),USE=PRIVATE 


Other samples for simplification of system operation using a OCCF CLIST 
are included in Appendix A. Two of the clists are used to allow GFT to be 
executed from any source that can submit OS commands. Here OCCF's auto- 
matic message reply facility is used. GTF can be started and stopped 
Without further operator action (GTF normally requires a reply from the 
operator at the MVS console). This allows invoking GTF from an NCCF ter- 
minal by using the NCCF command processor 'MVS' (see the description of 
the "MVS" command processor earlier in this chapter). All the NCCF user 
has to enter is: 


MVS /STARTGTF or 
MVS /STOPGTF respectively 


Gathering of line trace or VTAM buffer trace data is a common task for 
problem determination. VTAM buffers regarding cross-domain traffic 
between a terminal and an application can only be traced in the host of 
the primary session partner. In a centrally controlled configuration that 
1s normally a sub-host where the application runs. The STARTGTF/STOPGTF 
CLISTS in conjunction with the 'MVS" command processor allow traces to 
start and stop in a remote sub-host from any NCCF terminal. (Note that 
ee oes for a remote sub-host can be issued from one NCCF/OCCF termi- 
nal only). 


Reduction of operator intervention 


Here are two samples how operator intervention is substituted by automat-— 
ically invoked CLISTs. The first one is a sample for reactivation of an 
IBM 8100/DPCX subsystem. When a DISABLE HOST command is executed in a 
DPCX subsystem, DPCX sends an SNA request for a discontact which makes 
VTAM issue the message 


IST169I DISCONNECTION CAUSED VARY INACT FOR PU = ..... 


and deactivate the PU. This 1s a normal procedure when IBM 8100/DPCX is 
brought down e.g. in the evening. But the PU representing the IBM 
8100/DPCX subsystem has to be reactivated by an VARY ACT command in order 
to allow reactivation of the IBM 8100 the next morning. To relieve the 
network operator of issuing VARY ACT commands in such cases, the NCCF 
facility to intercept a VTAM message and execute a specific CLIST instead 
is used in the sample under headline "NCCF CLIST to reactivate selected 
PUs after msg IST169I" on page 60. The CLIST called IST169I is executed 
every time VTAM issues message IST169I ... . The message together with a 
VARY ACT command for the disconnected PU is then issued by the CLIST. 


The next sample shows how the NCCF command EVERY can be used for automatic 
revival of failed system functions. If you have a look at the NCCF ini- 
tial CLIST shown under headline "NCCF initial CLISTs" on page 64 you can 
see an EVERY command which is coded to schedule execution of a CLIST 
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called MONITOR every 30 minutes after NCCF initialization. The CLIST MON- 
ITOR in turn invokes the OCCF CLIST SYSMON through the 'MVS' command 
processor (see CLISTs under headline "CLISTs for system monitoring"™ on 
page 60). In an OCCF CLIST you can code nearly any type of MVS or JES2 
command. The commands in the sample CLIST SYSMON are defined to care. 
about restart of NJE, NJE lines, and NJE to NJE sessions. NJE lines may 
temporarily go down or NJE to NJE session can be disrupted e.g. by a route 
failure but JES2 does not try to restart them. By applying the described 
technique NJE can be automatically restarted after a temporary failure 
Without operator intervention. This is important particularly for NJE in 
an unattended sub-host. | 


It should however be noted that all facilities to automatically restart 
components have to be developed in a way that they are not triggered if 
the component is deactivated deliberately. It is also recommended for 
other types of automated procedures that the possibility to overwrite 
automatic operations should be retained. 


Tailoring of VTAM messages 


Care should be exercised when tailoring VTAM messages. In no case should 
any VTAM message that is part of a full-screen message be modified. When a 
full screen message is processed by NCCF, the VTAM messages that are not 
modified are presented first and then the user modified messages. If the 
first message or the last message is modified by a clist, NCCF may not 
present any data. 


NPDA VERSION 2 


NPDA is a tool to automatically collect statistical data and information 
about unusual events within a network and store it into a data base for 
later display at an NCCF terminal. Beyond this, NPDA Version 2 now pro- 
vides alert handling capabilities. Alerts, which are indications of high 
priority events, can be presented to the network operator, as soon as the 
alert triggering event occurs. In many cases, the network operator is now 
ape to peace to failures of network components much sooner than with NPDA 
ersion 


Compared to NPDA Version 1, the new alert handling capability is more a 
new approach to present the data rather than a collection of new data 
about unusual events. Alerts are stored in the NPDA data base and dis- 
played to the user in a reverse-chronological order and are not organized 
by components. They may be presented on an NCCF screen in: 


e A dynamic display -- a single display that is updated each time NPDA 
builds and stores an alert. 

e A static display -- a 'frozen' version of the single page dynamic dis- 
play that allows the user to easily read rapidly accumulating alert 
data. 

° A history display -- a multi-page display of all alerts stored in the 


NPDA data base. 
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NETWORK PROBLEM DETERMINATION APPLICATION 02712782 10:50:18 
NPDA-30B * ALERTS-STATIC 
DOMAIN: NCF1il 


SEL# DATE/TIME TYPE RESNAME ALERT DESCRIPTION: PROBABLE CAUSE 

02/12 10:49 LINE L14040 LINK TIMEOUT:LINE DISABLEDC(PRIMARY END)/COMMUN. 
02/12 : LINE L24030 MODEM ERROR:LOCAL MODEM OFF/LOCAL MODEM 

02/12 COMC N245F3N ADAPTER CHECK:COMMUN. CTRLR. PGM/COMMUN. CTRLR. 
02/12 CTRL COMMUNICATION ERR: DEVICE/REMOTE MODEM INTERFACE 
02/12 LINE LINK TIMEOUT:LINE DISABLEDCPRIMARY END) /COMMUN. 
02/12 ADAP 1D "N" GROUP TIMEOUTS: DEVICE/COMMUNICATIONS 

02/12 LINE MODEM ERROR: LOCAL MODEM OFF/LOCAL MODEM 

02/12 CTRL COMMUNICATION ERR: DEVICE/REMOTE MODEM INTERFACE 
02/12 CTRL LINK TIMEOUT: LINE DISABLEDCPRIMARY END)/COMMUN. 
02/12 ADAP YWN™ GROUP TIMEOUTS: DEVICE/COMMUNICATIONS 

02/12 ADAP 1D "N" GROUP TIMEOUTS: DEVICE/COMMUNICATIONS 

02/712 CTRL POGOAODEE POWER OFF DETECTED:REMOTE PROBE POWER OFF/PROBE 
02/12 08: PROG 04B6 ACCESS EXCEPTION-SECONDARY PSV:PROGRAM 

02/12 08: PROG 04%B6 ACCESS EXCEPTION-SECONDARY PSV:PROGRAM 


DEPRESS ENTER KEY TO VIEW ALERTS-DYNAMIC OR ENTER ‘'A* TO VIEW ALERTS-HISTORY 
ENTER SEL# CACTION),OR SEL# PLUS * M* (MOST RECENT),' P'CPROBLEM),' DEL*CDELETE) 
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Figure 7. Example of NPDA Alert Static Display 


The NPDA dynamic display of alert data is an outstanding tool for monitor- 
ing an SNA network. This is especially true in an environment with a cen- 
tral network processor, because all irregularities of the network can be 
focused to one location. Depending on the size and complexity of the net- 
work it might be a good idea to have one NCCF screen as a monitor just for 
NPDA alert dynamic display or even have several such monitor screens each 
for a specific part of the network. 


It should be noticed that an NCCF screen which is in 
° NPDA alert dynamic display mode and also 
e receives the unsolicited messages 


cannot run without operator intervention. NPDA alert dynamic display mode 
15 a full-screen display which is not intermixed with the NCCF presenta- 
tion of the unsolicited messages. Although a switch from NPDA display mode 
to NCCF display mode is done automatically, the NCCF operator is forced by 
NCCF to confirm a reverse switch. For example, if the NPDA alert dynamic 
display 1s shown on the screen by the time NCCF wants to present unsolic- 
ited messages, the screen is cleared and the messages appear at the upper 
lines of the screen. If afterwards NPDA wants to present an updated alert 
display, *** appears at the lower left corner of the screen as an indi- 
cation that the operator has to press the ENTER key. After doing that, the 
latest NPDA Alert Dynamic Display is shown on the screen. This technique 
is independent of the NCCF autowrap mode which normally allows running an 
unattended NCCF session. 


The NPDA alert history display can be used as a complete record of prob- 
lems which exist in the network and which need attention by the network 
operator. To achieve this, all the network operator has to do is to delete 
those records from the NPDA alert part of the data base which tell about 
resolved problems or problems which have been already reported to other 
departments for solution. Records deleted from the history display can 
still be viewed on event or statistical data displays. So the NPDA alert 
history display used in this way is a good tool e.g. 


e for operator communication e.g. at shift change. 
® to relieve network operators of reporting minor problems somewhere 
else. 


The technique described above may require reducing the alerts presented by 
NPDA to those which really demand some action. NPDA allows to reduce the 
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data collected or displayed by means of filters. Recording filters in 
NPDA can be used by an installation to control what data should be 
recorded in the NPDA data base. Viewing filters allow each operator to 
control what data should be displayed on his terminal. Each of these fil-. 
ters consists of a number of entries, created with NPDA SRFILTER or SVFIL- 
' TER commands. By means of these commands NPDA is told to either 'block'* 
recording/viewing of events or to let them 'pass'. The following filter 
criteria can be specified: | 3 


° Event types, e.g.: performance, permanent errors 
e Resource names 
e Resource types, e.g.: communication controllers, lines 


Because NPDA filters are stored only in main storage an NPDA users viewing 
filters are lost after logoff and recording filter are lost after NCCF 
close down. The filters can be automatically restored by the NCCF initial 
CLIST or by a users initial logon CLIST (see "NCCF initial CLISTs" on page 
64 for a sample). | 


NPDA also provides for the transfer of selected information to the 
INFO/Management feature of the INFO/System program product. To transfer 
problem descriptions from the NPDA data base to INFO/Management data base 
all the NPDA user has to do is to locate the problem description on an NPDA 
display and enter the selection number which represents the problem fol- 
lowed by the character P (see Figure 7 on page 17 for an example display). 
The information issued by NPDA can then be supplemented under 
INFO/Management during further tracking of the problem. 


NPA 


One of the tasks network operation comprises is surely to look after cer- 
tain performance degradations. Without having appropriate tools to dis- 
cover the reasons for performance problems you are often dependent on, 
speculations and your approaches to resolve such problems are not always 
based on the facts. In the communication network area NPA is a tool which 
gives you a lot of information about what is going on in communication 
controllers or NCPs respectively. It tells you e.g. about 


° IBM 3705 utilization 

° NCP buffer utilization 

° message queues within the NCP 
® message rates 


e byte rates 


e negative poll rates 
° line utilization 
° temporary errors 


An NPA user can get this data from any NCP in the network if the NCP was 
generated to support NPA . Thus there is no necessity to run multiple NPAs 
in a centralized network. With the data provided by NPA, performance 
problems caused for instance by | 
° long NCP outbound queues 

e insufficient line capacity 

e excessive traffic at certain periods 
¢ IBM 3705 over utilization 


e high error rates for lines, clusters, etc. caused by temporary errors 
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can easily be identified. Although temporary errors are also counted by 
NPDA, the figures from NPA are quite different. Whereas NPDA tells you the 
number of temporary errors for a specific number of messages, NPA gives 
you the number of temporary errors per time interval. For some kinds of 
problems it is just as important to know the time when the errors occur as 
the traffic/error ratio. Here is an example: You have poor response times 
between 3 and ¢ o'clock in the afternoon on some of your terminals con- 
nected via switched lines. NPDA tells you that you have an average 
percentage of temporary errors on these terminals. When you start col- 
lection and display for these terminals on NPA you can see that temporary 
errors between 3 and 4 o'clock increase heavily. It is now very likely 
that the reason for the long response times is an overload of the public 
network. 


With its monitor function, NPA supports the network operator with an alert 
capability in addition to the one provided by NPDA. Low and high threshold 
values can be defined for things like 


° negative or positive poll rates 
e line utilizations 

° message rates 

° error counts 


° IBM 3705 utilization 


When the data falls outside these limits, an exception message is dis- 
played at the NPA terminal. As an example, the operator can specify a low 
limit of 1 message per minute for a cross-subarea link. If the message 
rate on that link drops below 1 message per minute NPA alerts the operator 
by displaying a highlighted monitor message and sounding the alarm on the 
3270 screen. This message is then interpreted by the operator as an indi- 
cation of potential problems at either end of the link. 


CICS/VS AND IMS/VS 


CICS/VS and IMS/VS do not cause any specific problems in a centrally con- 
trolled multi-host environment. The master terminal function for any 
those subsystems can be made available in many different ways at the cen- 
tral site. This is described in the next chapter in section "CICS/VS and 
IMS/VS master terminal™ on page 28. Multiple physical routes should be 

oes to preserve accessibility from the central site to the subsys- 
ems. : 


Running CICS/VS or IMS/VS on a remote sub-host with the master terminal 
operator at the central site seems to be possible in many cases. There is 
no need for people skilled in data processing to operate the remote sys- 
tems if their operations comprise just a few, well documented inter- 
ventions. You may also think one step further of an unattended remote 
system. With the ROCF facility ef an IBM 4300 processor you can do a 
remote IML/IPL. Physical operation is however still required in some 
areas as e.g. IMS/VS requires mounting of log tapes on a tape drive. But 
this does not mean, that the remote system has to be attended all the 
time. During the day, remote operation could be done on an alert basis, 
where the alert comes from the central operator. 


INFO/MANAGEMENT 


Within section "NPDA Version 2" on page 16 or a following page there is a 
description of how to use the problem management facility of 
INFO/Management in conjunction with NPDA. To illustrate all the possibil- 
ities of 

Problem Management | 


Change Management and 
Configuration Management 
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by means of INFO/Management is certainly Beyond the scope of this paper. 
Therefore only one sample is given here to show how information data is 
presented by INFO/Management: 


‘An installation using configuration management in INFO/Management enters 
descriptive information about hardware and software system components 
into the INFO/Management data base. This information can be used e.g. by 
the network operator for his specific needs. Let's assume he has a problem 
with a display control unit and wants to know who is responsible for that 
device. For that purpose, he enters the INFO command under NCCF or TSO and 
gets the INFO/System Primary Options Menu Display in response. He then 
enters a command e.g. ‘DISPLAY R AB16' to get the Hardware Component Dis- 
play for the device AB16: 


BLGON100 HARDWARE COMPONENT DISPLAY COMPONENT ID: AB16 


Generic device CTL Component status <H> INSTALL 

Device type & model Date of status <H> 03711782 
Serial number Network name PI4GOA0F 

Order number Node name...... ccc cece NIGBF3N 

Microcode EC level Program name 

Date shipped LTERM ID CIMS) 

Lease begin date 

Lease end date 


Description ; 3274 CONTROL UNIT 


SELECT ONE OF THE FOLLOWING, OR REPLY 'QUERY' FOR AVAILABLE SUBCOMMANDS 


Hardware component display . Up component ID display 
Hardware support display . Line information display 
Hardware EC level display . Up component list display 
History display . Down component list display 
Freeform text and notes . Up & Down synopsis display 
Feature list display . Connectivity path entry 


Figure 8. Example of INFO/Management Hardware Component Display 


When he then enters a 2 he will get the desired information on the 
INFO/Management Hardware Support Display: 
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BLGON150 HARDWARE SUPPORT DISPLAY COMPONENT ID: AB16 

Component owner <H> RSC Center ID 

Transfer-to class...<H> System ID 

Contact name <H> GTAYLOR Finance ID 

Contact department D40 Service ID 

Contact phone 312-245-3000 Owning priv. 

Maintenance interval... __ Entry priv. 
Date entered 03/01/82 
Time entered 11:33 
Date last altered...<H> 03/01/782 


SELECT ONE OF THE FOLLOWING, OR REPLY "QUERY" FOR AVAILABLE SUBCOMMANDS 
Up component ID display 


Line information display 
Center ID display 


Hardware component display 
Hardware support display 
Hardware EC level display 


History display 
Freeform text and notes 
Feature list display 


System ID display 
Financial ID display 
Service ID display 


Figure 9. Example of INFO/Management Hardware Support Display 


Note: The name of the control unit AB16 is independent of its network node 
name. 


Performance considerations. Based on user experiences with NCCF and 
Information/System, it is reccommended that only the NPDA to 
INFO/Management interface be used whith  NCCF. Further use of 
INFO/Management should be done vis a TSO session. This TSO session can be 
made through the TAF interface of NCCF. This technique does not impact the 
performance of NCCF and does not require the virtual storage of NCCF to be 
expanded 800K bytes for each INFO user. 
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CHAPTER 4: SYSTEM AND NETWORK ACTIVATION 


Activation of a centrally controlled multi-host configuration can be 
divided into the following major parts: 


1. Activate systems (central host and sub host(s)) 
2. Activate network 
3’. Establish central control 


As central operation implies the trend to reduce remote sub-host operation 
as far as possible, here the most interesting question is probably: How 
much sub-host operator action 15 necessary before the sub-host can be con- 
trolled by a central operator? The answer to the question depends of 
course on many factors but the general answer is: 


e System activation of IBM 4300 sub-hosts 1s possible from a remote cen- 
tral site. 


® All other IBM 7370 sub-hosts have to be activated from the sub-host 
site. 


Activation of a multi~host SNA network with all its components can be a 
very complex process and it 1s nearly impossible to cover all the con- 
straints of real installations in a paper like this. The procedures 
described here are just samples to show what is possible with the current 
state of the products. Subjects covered by this chapter will illustrate 


° how a central host, sub-host(€s), and a network can be activated with 
very few operator interventions. 


° how a central host operator is able to take over control of sub-hosts. 
e how CNM products can help in the system and network activation 
process. 


ACTIVATION OVERVIEN 
Here is a step by step overview how system and network activation is cov- 
ered in this chapter: 
is IPL 
2. Automatic start of VTAM, OCCF, NPDA, NCCF 
3. Execute MVS/OCCF CLIST which 
° starts applications e.g.: TSO, CICS/VS, IMS/VS, etc. 
° issues MVS and JES2 commands to start e.g. NJE and lines 
° activates NCPs and locally attached 3270 control units 
4. Establish NCCF to NCCF sessions 


5. Transfer MVS consoles logically from sub-hosts to the central NCCF 
operator by establishing NCCF to OCCF sessions 


6. Make the master terminal operator function (of sub-host's CICS/VS and 
IMS/VS available at the central site 


MVS operator commands except JES2 commands can be put into a COMMNDxx mem- 
ber of the SYS1.PARMLIB data set. These commands are internally issued by 
the system at system initialization time. JES2 itself is automatically 
started by the standard MSTRJCL definition in the SYSI.LINKLIB data set. 
So JES2 and some routine procedures can be started by standard MVS func 
tions. But when one procedure requires another procedure to be started, as 
TSO requires VTAM, this standard facility is not sufficient. 


Chapter 4: System and network activation 23 


In order to manage the scheduling of automatic starting procedures during 
the system activation process an MVS/OCCF CLIST can be developed which 
provides for starting VTAM application programs and initialization proce- 
dures with little or no operator intervention. Using this technique, all 
the operator 1s required to do is to perform the basic IPL procedures such 
as specifying system parameters, answering the IPL reason and then start 
the OCCF CLIST. 


The procedure described here takes care of activating the resources in the 
system. It is useful not only on the sub-host but also on the central host 
to 


® avoid operator mistakes during system activation 
e reduce the skill needed for system activation 
° speed up system activation 


IBM 4300 sub-host processors can be IPLed and activated from the central 
site without intervention at the sub-host site by using ROCF, a VTAM inae- 
pendent tele-access capability. 


After the system and the network are initialized the central operator can 
take over control of the whole network by logging on to the sub-hosts 
NCCFs. In addition to commands, CLISTsS, and replies that relate to the 
network NCCF can be used as a port to 


® a sub-hosts system console (via OCCF) 
° control sub-hosts applications like CICS/VS and IMS/VS (via NCCF/TAF 
or OCCF) 


The following shows the system activation process in more detail: 


Note: Procedures and CLISTs mentioned throughout this chapter are concen- 
trated in "Appendix B. System and network activation: Sample definitions" 
on page 63. | 


IPL 


Cereal 


The operator executes the IPL and replies to some standard MVS messages 
such as 


TEA846I SYSTEM CONSOLE INTERFACE UNSUCCESSFUL. 
TEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2,VER=SP1.3.2 JBB1328 


an 
IEA347A SPECIFY MASTER CATALOG PARAMETER 


COMMNDXX 


The MVS system initialization causes JES2 to be started and the commands 
defined in the COMMNDxx member of the SYSL.PARMLIB data set to be executed 
automatically. The significant commands issued by COMMNDxx definitions 
are: 


START VTAM and 
START OCCF 


If OCCF, NCCF, and NPDA should run on the same system then starting OCCF 
does include starting of NCCF and NPDA because they are all placed in the 
same MVS address space. This in turn leads to a synchronization problem 
because NCCF needs an active VTAM to open its ACB. If the NCCF application 
node in VTAM is not in the state of CONCT (connectable) by the time NCCF 
comes up then NCCF writes the message 


nn DSI800A REPLY 'RETRY',*SHUTD' OR ‘ABEND!’ TO PROCESS 
NCCF OPEN ACB FAILURE | 
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to the system operator console. This message can be automatically replied 
to with RETRY by OCCF because OCCF has an Automatic Reply function and 
OCCF is already active when NCCF writes out this message. If after retry 
VTAM is not up yet, the same NCCF message comes again and is again replied 
to by OCCF with a few seconds delay. This sequence might be repeated 
several times until finally VTAM, OCCF, NCCF, TAF, and NPDA are all 
active. 


NCCF INITIAL COMMAND OR CLIST 


Some activation of the network can be done by specifying a CLIST or a com- 
mand in the NCCFIC definition statement for automatic execution after NCCF 
is initialized. This initial command or CLIST execution can be used for 
instance to activate NCPs or set NPDA recording filters. 


NCP _ ACTIVATION 


All the NCPs in the network have to be activated from the central host to 
form centralized network control. The NCPs which are channel attached to 
remote sub-hosts have also to be activated from the respective sub-host to 
link the sub-host to the network. Activation of an NCP may include IPL of 
the IBM 3705. VTAM makes the decision and automatically reloads the IBM 
3705 if necessary provided that 


AUTOSYN=YES and 
VFYLM=NO 


was coded in the PCCU macro instruction for the NCP and the NCP was acti- 
vated by an 


V NET,ACT,ID=....,LOAD=U 


command (LOAD=U is also the default). NCPs should not be activated by 
specifying them in the ATCCONxx member of the SYS1.VTAMLST data set. The 
better way is to activate them after NCCF and NPDA are up to ensure that 
errors occurring during NCP activation are recorded in the NPDA data base. 


The commands to activate the NCPs can be put into the NCCF initial CLIST 
or an OCCF start-up CLIST Csee "MVS/OCCF start-up CLIST"). This allows to 
automatically activate NCPs at system initialization time without issuing 
VARY ACT commands manually by the operator. 


Remote IPL of an IBM 3705 across a link not always works without inter- 
vention at the remote site. Depending on the state of the IBM 3705 it is 
sometimes necessary to hit the load button in order to get the box loaded. 
Provisions have to be made, that someone is available at the remote IBM 
3705 location to do this if required. 


An IBM 3705 can be equipped with channel adapter(s) plus Remote Program 
Loader (RPL). This allows central site IPL of an IBM 3705 which is channel 
attached to a remote sub-host. Remote loading of a channel attached IBM 
3705 can be done e.g. for backup reasons in case of a sub-host failure. It 
should however be noted that the RPL can only be used if the IBM 3705 is 
detached from the host processor's channels. The RPL is activated by manu- 
ally switching off all the channel adapters at the IBM 3705 console. This 
has to be considered for planning of an unattended remote sub-host. 


MVS/OCCF START-UP CLIST 


MVS or JES2 commands which are normally entered to a system console can be 
put into an MVS/OCCF CLIST for execution when required. This facility can 
be used here to start TSO, CICS, IMS, etc. If the applications require 
certain operator replies, OCCF can be used to automatically do that. How- 
ever, because OCCF always replies to a specific message id with a specific 
response this approach is not possible for instance in IMS/VS. 
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The OCCF start-up CLIST can also be used to start NJE. The SNA part of NJE 
is a VTAM application within JES2. Here is a little problem, because JES2 
is started before VTAM and JES2 therefore can not open its VTAM ACB at 
initialization time. NJE has to be started by JES2 operator commands 
after VTAM is active. By defining these commands in the OCCF start-up 
CLIST an automatic NJE start can be provided. 


Depending on the requirements of an installation it might be a good idea 
to bring up some part of the network after the applications are active. 
This can prevent a flood of messages like 


IST264I SESSION SETUP FOR PLU = .... SLU = .... FAILED- 
REQUIRED RESOURCE .... NOT ACTIVE 


caused by end users trying to logon to an application that is not active. 
So activation of NCPs, local control units 3270, etc. can also be done by 
putting the proper VTAM commands into the OCCF CLIST. 


The OCCF start-up CLIST has to be invoked manually by the operator because 
MVS/OCCF does not have an initial CLIST capability like NCCF. This can be 
done either through the system console or through an NCCF terminal. Before 
you can invoke OCCF CLISTs from an NCCF terminal you have to astablish an 
NCCF to OCCF session (same domain or cross domain). 


However, another technique 1s used in the samples shown in the appendix: 
The OCCF start-up CLIST (called *AUTO) is invoked by the NCCF initial 
CLIST. This is possible by the NCCF command processor 'MVS' which 1s used 
here to more automate the system activation. 


ACTIVATION SYNCHRONIZATION AND CHECKPOINT 


Thus far, similar procedures have to run on the central host as well as on 
every sub-host. The completion of the system initialization process is 
like a synchronization point. Before the central operator can take over 
control from a sub-host to the central host, the central host and the cor- 
responding sub-host have to reach this state. 


The nearly automated system activation procedure described here is almost 
sufficient in daily or weekly operation as long as the system is not 
changed. The result is that the operation procedure for IPL can be 
described in only one page of the operation manual. Even if the system is 
changed, and it requires 'CLPA*'t or JES2 to cold start, the OCCF procedure 
can still be used to start the applications. 


Another approach to system activation using the FDP SOF is described ina 
document called "CNM Managing Interconnected Systems, GG24-1533'., 


The activation of the network is normally combined with a flood of VIAM 
messages and it is nearly impossible for an operator to notice failures 
during the network initialization process. The central operator should 
check the most important network components right after activation com- 
pletion to identify the areas where additional activities are necessary. 
This should at least include a check of the subarea interconnection anda 
check whether something hangs in the network. If a CLIST is provided for 
a network check it should therefore contain a 


D NET,PENDING and a 
D NET,STATIONS 


as the minimum. 


ACTIVATION OF A REMOTE IBM 4300 BY ROCF AND MVS/OCCF 


The activation procedures described above can also be initiated and con- 
trolled from a central host on behalf of a remote IBM 4300 sub-host with- 
out any operator intervention at the sub-host site. That is possible via 
ROCF a feature of IBM 4300 processors which supports remote system con- 
soles over a switched BSC line. This support includes all types of opera- 
tion possible at a system console including IMLZIPL. As ROCF is a hardware 
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implementation it is independent of an operating system on the IBM 4300 
processor. ROCF supports an IBM BSC 3275 model 2 terminal as the remote 


console. 
OCCF has a function called Remote Start Up Facility (RSUF) which can be 
used to simulate the IBM 3275. RSUF is invoked from an NCCF terminal and 


requests some input from the user in order to establish the connection to 
ROCF in an IBM 4300 (see Figure 10). 


REMOTE IML/ZIPL FACILITY 
SELECT ONE OF THE FOLLOWING: 
1 = DIAL - DIAL A REMOTE SITE 
2 = DISC - DISCONNECT A REMOTE SITE 
3 = TERM - TERMINATE REMOTE IML/IPL COMMAND. 


WILL ALSO DISCONNECT IF A CONNECTION 
IS ACTIVE. 


TREQ - REQUEST MODE CHANGE 


TYPE SELECTED NUMBER HERE: 1 


IF 1 WAS CHOSEN, FURNISH TELEPHONE NUMBER FOR AUTODIAL 
OR * FOR MANUAL DIAL. 
ENTER TELEPHONE NUMBER OR * HERE: X 


Figure 10. ROCF support in OCCF: This panel is shown by OCCF when a 
user enters RSUF at an NCCF terminal. 


After the connection is established the NCCF terminal is logically made an 
IBM 4300 system console which allows any type of operation possible on 
such a console. So, to activate an IBM 4300 sub-host IML, IPL, start of 
jobs, CLISTs, etc. can all be done from an NCCF console at the central 
site. However, it is not necessary to keep this connection after the 
sub-host can be controlled from the central host through NCCF to NCCF and 
NCCF to OCCF sessions. As ROCF supports a switched connection, one cen- 
tral site port can be used to bring up several remote IBM 4300 sub-hosts. 


Another advantage of the ROCF facility is that the connection to the 
sub-host can be reestablished at any time after activation without dis- 
rupting anything at the sub-host. This makes trouble shooting from the 
central site possible for all kinds of problems which do not need manual 
intervention at the sub-host site. 


Note: As ACF/NCP does not support switched BSC lines, the port used for 
ROCF has to be generated as an EP line in the NCP. A DD-statement for the 
line has to be added to the JCL-procedure which is used to start 
OCCF/NPDA/NCCF. 


NCCF TO NCCF AND NCCF TO OCCF SESSIONS 


The NCCF to NCCF and NCCF to OCCF sessions are used to take over network 
and system control from a sub-host to a central host. Once the central 
host and the sub-host(s) are connected via cross domain link(s) and NCCF 
and OCCF are ready for communication, NCCF to NCCF and NCCF to OCCF ses- 
sions have to be established to further interconnect the systems. To do 
this, three commands have to be entered from a central NCCF terminal: 
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1. START DOMAIN=domain-id 
2. ROUTE domain-id,oper-id, password 
3. ROUTE domain-id,OCCF %Q@LOGON 


The commands have to be synchronized, because the operator has to wait for 
specific messages before he can issue the second and third command. 


The central NCCF operator must repeat this operation for every sub-host 
NCCF. To ease this tedious operation by the central NCCF operator, this 
sequence could be done by means of an NCCF CLIST (for a sample CLIST see 
"NCCF CLIST to establish NCCF-NCCF and NCCF-OCCF sessions" on page 67). 
It will relieve much of the host operator work every morning and also pre- 
vent the operator from forgetting to start some of the sessions. 


CICS/VS_ AND _ IMS/VS MASTER TERMINAL 


In order to control subsystems like CICS/VS and IMS/VS from the central 
host, the master terminal function of these systems needs to be available 
at the central site. There are several ways to achieve this. Tradi- 
tionally there are two possibilities to control CICS/VS and IMS/VS: 


1. From a dedicated master terminal 
2. From the MVS system console 


The first method is suitable for centralized network management because 
the central subsystem master terminal operator can logon to any subsystem 
from any terminal either same domain or cross domain. But, for every sub- 
system a physical master terminal is needed. 


The second method works only, when CICS/VS or IMS/VS run on the central 
host or on a host which is at the same location as the central host because 
an MVS system console is a locally attached terminal. 


Now both possibilities are expanded and the master terminal function of 
all subsystems in a network can be focused to one NCCF terminal. The TAF 
feature of NCCF allows communication from an NCCF terminal to CICS/VS and 
IMS/VS. The central operator can logon to CICS/VS and IMS/VS as a master 
terminal operator from his NCCF terminal via TAF. Without leaving his 
NCCF session he can enter CICS/VS or IMS/VS commands. | | 


The other way to direct the master terminal function to an NCCF screen is 
via OCCF. As mentioned earlier in this chapter, an MVS system console can 
be logically transferred to an NCCF screen. So, if sessions from the cen- 
tral host's NCCF to sub-host's OCCF are established, the MVS system con- 
sole functions of the sub-hosts are available at the central host. That 
means that master terminal operator commands can be entered at the NCCF 
console without any other initialization procedure. In the case of IMS/VS. 
for instance, the central operator can enter the IMS/VS commands 


/NRESTART 
“START DC 
“START REGION ... 


as replies to the IMS/VS messages 


nn DFS810A IMS/VS READY ........ or 
nn DFS996I *IMS READY*X .... ‘ 


to bring up IMS/VS . 


CICS/VS requires that the OCCF console has to be defined in the CICS Ter- 
minal Control Table (TCT) with the proper authorization. 


Note: The requirement to have all control functions directed through one 
Single operator interface should be carefully considered with regard to 
traffic and usability before installation of only one display console for 
operator control. 
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CHAPTER 5: FAILURE AND RECOVERY 


A multi-domain SNA configuration consists of a great number of interre- 
lated single components and there is a big chance at any time that some of 
these components are in an out of order state. The structure of the inter- 
relationship between the components is not always simple and makes it necy 
essary not only to provide for backup capabilities but also to prepare 
operating procedures for exception situations in advance. It is tmportant 
to simulate and test the failure of each component as well as multiple 
failures before the emergency case to make sure that the recovery works in 
the way expected. To be prepared for a failure of any component and be 
able to take the most appropriate recovery actions results in not dropping 
the service for the end users under a desired and possible level. 


This chapter contains some information necessary in planning recovery 
actions and provisions: 


° Failure and restart of different components 
e Impact of component failures on other parts of the network 
e Special operating procedures required to back up components 


Not all of the things mentioned in this chapter only relate to a centrally 
controlled environment but they may still be helpful for the operation of 
such a configuration. 


Note: The failures which are covered in this chapter are of those types, 
where the component 1s not available at all for any reason. Other types of 
failures such as intermittent errors on a modem, a software error ina 
cluster controller, etc. are often not so evident and require effort in 
problem determination, isolation, and recognition. As this i858 a complex 
subject on its own, it 1s not dealt with in this paper. 


SESSION FAILURE 


Logical connections between network components are called sessions in 
SNA. These sessions may be disrupted by a network component failure such 
as a failure of VTAM, an NCP, a line, and so on. Bafore the failures of 
different components are discussed here in this chapter, session dis- 
ruption and recovery is covered more generally in this section. 


As the reason for having a network is servicing the end users, the impact 
of network component failures on the user's data sessions has always to be 
considered. These sessions are called LU to LU sessions where the LU at 
one end is always an application program ina host and the LU at the other 
end can be a terminal such as an IBM 3277 display unit, or another appli- 
cation program located either in a host or. ina cluster controller such as 
an IBM 8100 subsystem. LU to LU sessions are used to transfer user data. 


Before an LU to LU session can be established (e.g. by logon to an appli- 
cation program), other sessions called control sessions have to be active. 
One session partner of the control sessions discussed here is always the 
System Service Control Point (SSCP) in VTAM. The other session partner can 
be another SSCP, an NCP, a cluster controller, or an LU. All these ses- 
sions are used for different tasks of network control. The control 
sessions are not always evident in the operational environment, though 


e an SSCP to SSCP session is established by activation of a CDRM in 
another domain. 


° an SSCP to application session is established when the application 
opens its ACB. 


e an SSCP to PU/LU session is established by activation of the PU or LU 
respectively. 


The following figure shows a sample which gives an overview of the. control 


sessions needed to support a single terminal to application cross-domain 
session. | 
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Central | | Oe | Sub- 


host NCP | NCP host 
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SSCP to SSCP CCDRM-CDRM) session 

SSCP to PU C(CNCP) sessions 

SSCP to PU (cluster controller) 
session 

SSCP to LU (terminal) session 

SSCP to LU Capplication) session 

LU to LU Cterminal to application) session 


O U1 Ne 


Figure 11. Sample sessions ina multiple domain configuration: The 
central host controls the PUs and LUs of both NCPs 


In an SNA network, a non-recoverable failure of a network component breaks 
all sessions using that component (failure of a link in a multiple link TG 
is an exception). SSCP to PU/LU sessions can be automatically recovered 
by VTAM in case of a route failure, if there is an alternate route avail- 
able. This allows an end user to re-logon to an application using a dif- 
ferent route without operator intervention if his LU to LU session was 
also disrupted by the route failure. There are some more types of fail- 
ures or types of sessions which are automatically recovered by VTAM. They 
are discussed later in this chapter. Reestablishment of broken LU to LU 
sessions and other sessions which are not recovered by VTAM, has to be 
done for instance by the. end user, by the network operator, by automat~ 
ically called NCCF CLISTs or by VTAM application programs. 


VTAM allows separating the control sessions and the user data sessions by 
using different routes for them. This can diminish the impact of a ses- 
sion failure on other sessions and is especially true in case of the CDRM 
to CDRM session. Other cross-domain sessions can continue undisturbed if a 
CDRM to CDRM session fails. | 


When an SSCP to NCP session fails, e.g. by a VTAM failure, the NCP also 
breaks the SSCP to PU and SSCP to LU session for all resources which were 
activated by the lost SSCP. The LUS cannot establish new LU to LU sessions 
as long as VTAM has not reestablished the SSCP to NCP and SSCP to PU/LU 
sessions. The survival of the existing LU to LU sessions depends on vari- 
ous factors: | 


End users whose LU to LU sessions are not directly affected by the failure 
can continue their sessions if they use SNA terminals on none-switched 
lines (for the PU they are using, ANS=CONTINUE must be coded in the NCP 
deck). When VTAM reactivates the SSCP to NCP session it also tries to 
regain control over its physical and logical units by reactivating them. 
This process may disrupt the survived end user sessions. ACF/VTAM uses the 
SNA requests ACTPUCERP) and ACTLUCERP) when activating physical units and 
logical units, respectively. PUs and LUs which do not support these com- 
mands break existing sessions whenever they are activated by VTAM. At this 
time only a limited number of cluster controller types as for instance the 
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IBM SDLC 3271732743275 support ACTPUCERP) and ACTLUCERP). The existence 
of ACTPUCERP) and ACTLUCERP) support is relevant in all types of failures 
where the SSCP to PU/LU sessions are broken but the terminal end user's LU 
to LU sessions are not touched. This can be for instance a VTAM, NCP or 
route failure. Let us have a look at the following figure to illustrate 
same examples: 


Sub- Central Sub- 
host 21 host ll NCP14 NCP 04 host O01 


A 
p 
p 
L 


Terminal 3 Terminal 5 


Terminal 1 att 


to 3274/SDLC 3275/SDLC | 3276/SDLC 
XS SSSlssSez Sos mo perenne iany mp nama 
Terminal 2 att Terminal 6 
to 3274/SDLC 3275/BSC 
Ronsssssssssscss| Terminal 4 att SS=SsSsSctssssXx 
to 3274/SDLC 
RSSSSSSSSSSsSezz= 


Figure 12. Sample of different LU to LU sessions 


It is assumed that all terminals in the figure above are owned by the cen- 
tral host's VTAM. The impact on the end user's terminal to application 
sessions differs for different failures and terminal types. The failures 
considered here, are failures of VTAM on host 11, NCP14, and the 
cross-subarea link between NCP14 and NCPO04. 


Terminal 1 will lose its session if VTAM on host 11, or NCP14 fails (be- 
cause this will break the LU to LU session) 


Terminal 2 same as terminal 1 


Terminal 3 will lose its session only if NCP14 or the link between NCP14 
and NCP04 fails (because this will break the LU to LU 
session) 


Terminal 4 can keep its session for all the above described failures 
even after restarting the failed components 


Terminal 5 can keep its session for all the above described failures up 
to the time when the failed component is reactivated. The 
reestablishment of VTAM's session to the IBM 3276 PU and LUs 
Will break all LU to LU sessions of that device because the 
IBM 3276 does not support ACTPUCERP) and ACTLUCERP). 


Terminal 6 is a BSC terminal and will lose its session immediately after 
the SSCP to NCP session failure, which happens in all the 
above described cases. 


The survival of an LU to LU session as described above, is not dependent 
on whether the same or another VTAM reestablishes the VTAM to PU/LU ses- 
sions. For instance, if in case of a permanent failure of the central host 
11 VTAM on sub-host 01 would be used to take over NCP14 and NCP04 to con- 
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trol their network resources, then the ongoing sessions of Senne. 3 and 
4 would not be disrupted by this process. 


The above description about sessions and session failures ated het that 
a look at the sessions necessary to run an SNA network and the impli- 
cations of different session failures should be considered and could 
influence network planning and configuration. In case the natwork termi- 
nals support ACTPUCERP) and ACTLUCERP), complete separation of the net- 
work and application functions to different host processors can be 
advantageous. You have a sample of this in Figure 11 on page 30 where no 
VTAM end user applications run on the central host processor (applications 
used to control the network and the systems are still necessary). Sucha 
configuration is also known as a Configurations Management Configuration 
or Chic. A CMC can improve the availability of the network for the end 
users. In such a configuration a failure of the central processor is not 
any longer a very serious problem as the network does not need control 
functions continually. If the central host can be reactivated or backed 
up rapidly, the effects of its absence on the network as a whole are mini- 
mal and most of the users would not even notice it as long as they do not 
logoff or logon. 


HOST FAILURE, RESTART, AND BACKUP 


Failure of a host means that VTAM and all applications go down. Applica- 
tion subsystem data recovery and transaction resynchronization can be 
required. The impact on the end user sessions depends on many factors as 
described in section "Session failure™ on page 29. In addition, the fail- 
ure of the network control host means complete loss of central control. If 
reactivation of the host is possible, it does not differ very much from 
the initial activation process. 


Host backup 


If the failure of a host is expected to take a long time to recover (as in 
the event of a major hardware failure) it would be necessary to backup 
that processor. A backup host is normally channel attached to the ori- 
ginal host's DASD drives and communication controllers. Locally attached 
terminals Ce.g. IBM 3270) should be switchable between the original and 
the backup host. You can think of some exceptions to this but provisions 
have to be made that at least the original host's data is available at the 
location of the backup host. 


From the view of network operating however, it is independent of whether a 
backup host is at a local or a remote location. The configurations shown 
in this section are therefore only used to illustrate the text and do not 
imply configuration recommendations. The more important difference is 
whether a sub-host or the central host is to be backed up. Backup of a 
sub-host means transferring applications to another host. This may also 
apply to a central host but backup of a central host requires additional 
network operational efforts. Please refer to section "Applications ona 
backup host" on page 36 for network operation requirements of application 
transfers. 


Backup of the network control host 


The operator actions Aeaua ead to backup the eran host are depending on 
the resources available and the techniques used. The least complicated 
condition is the availability of a backup host which normally runs without 
VTAM or has VTAM just for test purposes. In this case the VTAM defi- 
nitions of the original central host can be used and because VTAM's sub- 
area can be retained there 1s not much difference from the initial 
activation process. 


It is certainly more common that the backup processor is one of the > 
sub-~hosts. In this host an up and running VTAM is used which has a subarea 
number different to the one normally used on the central host. The oper- 
ations necessary to be done on the backup host to regain control over the 
network and the sub-hosts are basically: 


1. Gain ownership of all NCP's network resources 
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2. Make the tools for network and sub-host control available on the back- 
up host 


NCP takeover 


In order to control network resources via VTAM commands, VTAM has to be 
the owner of the addressed resource or, in other words, the resource must 
be an element of a domain which is controlled by that specific VTAM. Own- 
ership also implies, that errors of a resource are reported to the owning 
VTAM(Cs). Some resources such as NCPs and cross~-subarea links allow shared 
ownership by up to 8 VTAMs. The NCP's PUs and LUs however, can belong to 
one VTAM only at a time. 


In a centrally controlled. network the central VTAM's domain can comprise 
all NCPs in the network either channel or link attached to the central 
processor and all of the NCP's network resources. In case of a central 
VTAM's failure and backup by another VTAM, takeover of the NCPs and their 
resources are possible without reloading the NCPs or even disrupting some 
of the current sessions with other hosts. This is made possible by a 
facility of the network control program called Automatic Network Shutdown 
CANS). By the ANS facility an NCP notices when it loses the ability to 
communicate with one of the owners of its resourcés. In such a case the 
network control program takes the following actions on behalf of the 
failed. VTAM: 


e It cleans up all sessions which end in or pass the NCP and end in or 

pass the failed VTAM. This does however not include deactivation of 

cross~subarea links. ANS=CONTINUE must be coded for PUs representing 

a 3705 and this garantees that the availability of such a link is not 
affected by ANS. | 


e The actions taken for LUS which have sessions to other domains and 
which are owned by the failed VTAM are depending on the type of termi- 
nal and the type of connection (Cswitched/non-switched, BSC/SDLC) as 
described in section "Session failure" on page 29. 


After ANS is processed by the NCPs, the domain of a backup host can be 
expanded by taking over the NCPs and their network resources. There are 
basically two methods to take over an NCP's network resources to another 
VTAM: 

1. by acquiring them 

2. by just activating them 
Either of those methods can be used in a centrally controlled network and 
either of them can be used to take over a locally attached NCP or a remote 


NCP attached via a cross~domain subarea link. 


For simplification of the following description the configuration shown 
in the next figure is used to illustrate the takeover operations. 
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CENTRAL SUB 
HOST ll HOST 21 


Figure 13. Sample Configuration: Two hosts share a single channel 
attached.NCP 


Gain ownership by acquire 


The first method has the advantage of being precise and of reducing the 
possibilities of operator mistakes. The requirements are that the NCP's 
network resources are pre-assigned to a specific VTAM. This is done by 
specifying the OWNER operand in the PCCU macro instructions and in the 
macro instructions that define the network resources (e.g. GROUP, LINE, 
PU, LU) as shown in the following figure: 


HOSTI1 PCCU ..... OWNER=HOST11 


HOST21 PCCU ..... OWNER=HOST21,BACKUP=YES 
P14020A PU ..... OWNER=HOST11 


Figure 14. NCP14 sample generation macro instructions: In addition 
to the OWNER operand, BACKUP=YES must be coded on the PCCU 
macro definition that represents a potential backup VTAM. 


In respect to the above figures, an operator can activate NCP14 with any 
SCOPE operand from host Ll and from host 21, but he can display, activate, 
deactivate PU P14020A only from VTAM on host ll. 


If the sub-host 21 has to backup the central host 11, the central operator 
has to acquire NCP14 by using the VTAM command 


VARY NET,ACQ,.... 


The acquirement is in fact the assignment of a new owner for a given 
resource. If the resource is also to be activated, the ACT operand can be 
specified as part of the VARY ACQ command. The VARY ACQ command can be 
used in various combinations with SCOPE and ACT operands, but in general 
it must first be issued for the NCP itself and after that an tndividual 
VARY ACQ is required for every PU to be acquired. This could be a source of 
mistakes and time consuming in a large network. Therefore, an NCCF CLIST 
is very helpful to facilitate the VARY ACQ operation. Such a CLIST 1s 
shown as a sample in the appendix under headline "NCCF CLIST to ACQUIRE an 
NCP" on page 62. 
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Gain ownership by activation 


The second method has the advantage that all network resources of an NCP 
can be taken over with only one VARY ACT command. This method requires 
that OWNER operands are not coded in the macro instructions that define 
the network resources. If a resource which cannot be shared has no 
pre-assigned owner, then the first VTAM to request activation of that 
resource becomes the owner. Thus, operational procedures have to be 
defined to achieve an orderly control of the NPC's resources. Referring to 
figure Figure 13 on page 34 the normal activation of NCP14 would be dif- 
ferent for the central host 11 and the sub-host 21: 


Host 11: VARY NET,ACT,ID=NCP14 


Host 21: VARY NET,ACT,ID=NCP14,SCOPE=ONLY 
VARY NET,ACT,ID=L14.... 
VARY NET,ACT,ID=L14¢.... 


The VARY ACT command on the central host 11 activates the NCP and all the 
NCP's network resources to their initial status. The first VARY ACT com- 
mand on host 21 only activates the NCP. This makes the NCP an operative 
part of the network routes of host 21. No lines, PUs, or LUS are activated 
by this command. The second and third VARY ACT commands activate 
cross-~subarea links for which sub-host 21 is a shared owner. 


In case the sub-host 21 has to backup the central host 11 the central 
operator on host 21 only has to issue a single 


VARY NET,ACT,ID=NCP14 


to take over NCP14. This has the same effect as the complete take over 
process as described for the first method. Again, the impact on the ongo- 
ing user sessions on NCP14 is described in section "Session failure" on 
page 29. 


Network and system control takeover 


To fully control the network and the other sub-hosts from the backup host 
the following operations are necessary: 


e Establish NCCF to NCCF and NCCF to OCCF sessions from the central 
backup host to the sub-hosts 


° Start CNM applications like NPA and HCF if they are not already active 
on the backup host 


° Regain control as a master terminal operator over subsystems like 
CICS/VS and IMS/VS 


Provisions have to be made that all the CLISTsS work properly on the backup 
host. E.g., NCCF's applid on the backup host differs from the applid on 
the original host. You have to take this into considerations if there are 
references to NCCF names in your CLISTs. These considerations should also 
relate to your network naming conventions as some other names are differ- 
ent when you run a backup central host. 


Another slight problem is the NPDA data base as NPDA does not support data 
base sharing between hosts. If it is desirable to continually record all 
network errors in one data base the central host's data base has to be 
made available to NPDA on the backup host. For that, you have to bring 
down NCCF on the backup host no matter whether NPDA is running on that 
host or not. This is because NPDA runs in the same address space as NCCF 
and OCCF and the data base is statically allocated by definitions in the 
JCL procedure used to start OCCF/NPDA/NCCF. A modified JCL procedure 
which allocates the central data base to NPDA is then used for the restart 
of OCCF/NPDA/NCCF on the backup host. The supposition for that 15s 
ee pe. that the data base is physically accessible from the backup 
OSs 


NCP take back 


After the failed central host has been revived, the NCP's resources have 
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to be returned to their original owner in order to control the network 
from there. Neither VTAM nor NCP support an NCP take over ‘in flight’. In 
general, the return of NCP resources to an original owner is disruptive 
for the sessions using the returning NCP. The non-shareable resources have 
to be deactivated on the backup host to make their activation from the 
original host possible. This will also break the LU to LU sessions. As 
cross~subarea links allow multiple ownership, their state can be pre-~ 
served during the take back operations. 3 


The description above implies that the reestablishment of network control 
from a backup sub~host to the central host is a process which can normally 
not be done during the main business hours. From the end user's point of 
view, the complete network would become unavailable for the time of the 
NCP take back procedure. However, if in case of a trade-off, it seems to 
be desirable to return NCP resources during a period of heavy network 
usage, there is an approach of a more soft take back. For that, the NCPs 
have to be artificially driven into ANS by disconnecting the backup host 
from the network. To disconnect a host from the network, the operator can 
deactivate the host's channel links. This deactivation breaks all routes 
between a host and the rest of the network, causing the NCPs to go through 
the ANS procedure with respect to the disconnected host. Channel con- 
nections are dynamically defined by VTAM when a channel attached NCP is 
activated. VTAM creates a name for a channel link and link station by 
using the communication controller's channel device name and adding -L 
for the link name and -S for the link station name. Channel links are 
addressable in a VTAM VARY INACT command. So, to disrupt a connection 
between a host processor and an NCP, activated e.g. through channel unit 
address 0C7, the network operator has to issue the VTAM command 


VARY NET, INACT,ID=0C7-L 


Such a command has to be issued for all NCPs channel attached to the back- 
up host. This will disrupt the LU to LU sessions with the backup host's 
applications but LU to LU sessions with other hosts can be preserved as 
during the failure of the original host. Thereafter, the same facilities 
as described earlier in this section can be used for NCP take back. 


APPLICATIONS ON A BACKUP HOST 


For different reasons, an application may run on a backup host under a 
subarea number different from the one it normally uses. In order to make 
this situation transparent to the users of that application, the applica- 
tion should keep its name as it is defined to VTAM. It implies that the 
CDRSC definitions for that application have to be changed. This can be 
done by the VTAM command 


F NET,CDRM=(Cnew-cdrm,old-cdrm) ,ID=cdrsc-name 
The command should be issued 


e when the application is started on the backup host. It has to be 
issued on all hosts in the network, which have defined the application 
. eo resource, with the exception of the backup host 
itself. . : 


® on every of the above mentioned hosts after IPL or VTAM restart, as 
long as the application executes on the backup host (this step can be 
avoided by using VTAM's configuration restart facility). 


When the application runs on its original host again, a command causing a 
reverse change has to be issued. 


All this is not a great thing but if it is forgotten, then complaints by 
the end users are inevitable. It should be therefore part of the opera- 
tional procedures used to shift applications from one host to another. 
CLISTs can be prepared to propagate such a change of network definitions 
throughout the network. 
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VTAM FAILURE 


At the current state of the product, ACF/VTAM seems to be a very reliable 
component in a communication network. Nevertheless, failure of VTAM is 
possible and it means that all sessions using that VTAM as a boundary or 
intermediate network node are disrupted. The recovery from a VTAM failure 
includes the following operations: 


1. Detect VTAM failure 
2 Reply to outstanding messages in TSO and NCCF 

3 Cancel other VTAM applications which are in a hung state 
4. Restart VTAM 

5 Restart OCCF/NCCF 

6 Restart other VTAM applications 

7 


Reactivate network nodes not included in VTAM's automatic start-up 
list 


8. Reestablish interrupted sessions. 


These operations can be more or less automated by means of CLISTS compara- 
ble to those used during system start-up. The proper commands and CLISTs 
have to be issued by the network operator and reestablishment of some of 
the interrupted sessions has to be done by the end user or by VTAM appli- 
cation programs. 


Additional problems arise in a centrally controlled environment. The cen- 
tral operator's control over a sub-host is completely lost when the 
sub-host's VTAM fails. An automatic recovery from such a situation might 
be desirable but is not explicitly supported by any of the CNM products. 
You can put operator commands required to do step 2 to 7 in an OCCF CLIST 
but this CLIST has to be invoked manually at the sub-host site. Neither 
OCCF nor SOF can detect a VTAM failure and NCCF is dead at that time 
anyway. If OCCF had a facility comparable to NCCF where a specific mes- 
sage (e.g. the message telling that VTAM failed) can be intercepted and 
trigger the execution of a CLIST it would be quite helpful for automatic 
recovery of a VTAM abnormal termination on a remote sub-host. 


Another possibility to recover from a sub-host's VTAM failure without man- 
ual intervention at the sub-host site is to restart VTAM manually from the 
central site. To do this, a VTAM tndependent access to the sub-host is 
required. In case the sub-host is an IBM 4300 processor the ROCF feature 
of these systems allows you to remotely access them via a switched line 
from a dedicated IBM BSC 3275 terminal or through MVS/OCCF. This access is 
hardware controlled at the IBM 4300 site and has nothing to do with any 
access method. Using ROCF makes the system console available at a remote 
site. With that a central operator is able to regain control of a sub-host 
and he can do the same things possible at a locally attached system con- 
sole of a remote sub-host including IML/IPL. 


There are other possibilities to remotely access sub-hosts independently 
of VTAM by using other teleprocessing access methods as for instance BTAM. 
As an example for that you can think of an NJE connection using BSC lines 
but those techniques are not further discussed here. 


CPRM_ FAILURE 


If a cross-domain resource manager fails, the central operator gets the 
message 


IST246I COMMUNICATION WITH CDRM ID=cdrmname LOST - REASON CODE 
among others. The failure of a CDRM to CDRM session in itself does not 
disrupt any other sessions. Naturally, new cross-domain sessions between 


the affected domains cannot be established as long as the CDRM to CDRM 
connection is down. As VTAM does not automatically restart a failed 
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cross-domain resource manager, message IST246I should trigger an NCCF 
CLIST which tries to restart the CDRM immediately. A sample CLIST is shown 
in the following figure. 


&CONTROL ERR | 

* IST246I COMMUNICATION WITH CDRM ID = cdrmname LOST - REASON CODE nn 
VARY NET,ACT,ID=&6 

&WRITE &1 &2 &3 &4 &5 &6 &7 &8& &9 &10 &1l 

BIRT TE 336 KE EK EEE EOE I HE DE DK HE HEE DE OE DE OK DK DE EE EE EE OE DEK KK EK EE KK EM EMM 
&WRITE CLIST IST246I COMPLETED FOR CDRM = &6 * 
SLR I TE 33334 3 EEE IE DE DEE OE DK EE HE HE OE BEEK HE HE DE EE OE EK EK EEK KK KK KN 
& EXIT 


Figure 15. NCCF CLIST for restarting a failed CDRM to CDRM session 
after message IST246I 


If the failure was because of a route failure and there is another opera-~ 
tive route to the corresponding CDRM, the CDRM becomes active again. If 
there is no other route to the other CDRM, the operator should be alerted 
every 3 - 15 minutes that a CDRM to CDRM session is lost. The way to do 
this, is to set the I/0 problem determination time-out interval through 
the VTAM command 


F NET,IOPD, IOINT=time-out interval in seconds 
to the proper value during network start-up. So, after failure of the CDRM 
and after the NCCF CLIST tried to restart the CDRM, the operator is noti- 
fied that a CDRM to CDRM session is in a pending state every nn seconds by 
VTAM messages 


IST530I AM GBIND PENDING FROM cdrm-name TO cdrm-name © 
IST532I EVENT ID=eventid 


where nn is the time specified in 'F NET,IOPD...' command. 


In a centrally controlled network, these messages remind the network oper- 
ator that he has lost control over a whole domain. 


CROSS-SUBAREA LINK FAILURE 


A cross-subarea link is always part of a network route anda transmission 
group (TG). The effects of a link failure are different depending on 
whether the routes using that link 

ds stay operative. 

2. become inoperative but alternate routes are available. 


3% become inoperative and no alternate routes are available. 


Routes stay operative 
If the failed cross-subarea link is part of a multiple link TG then no 
sessions are disrupted as long as one link in that TG is operative. The 


sessions will automatically use the remaining links of the TG but obvious- 
ly, performance degradation is possible. 


Routes inoperative but alternate routes available 


If the failed cross-subarea link was the only or last operative link ina 
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TG then all routes using that TG become inoperative. All sessions that 
used the failed link are dropped. The sessions can be reestablished on an 
alternate route and in case of the SSCP to PU/LU sessions this is done 
automatically by VTAM. For all other sessions there is no automatic 
recovery by VTAM. Reestablishment of the broken CDRM to CDRM and LU to LU 
sessions has to be done by the network operator, by CNM programs, by the 
end user, or by VTAM application programs. 


Routes inoperative and no alternate routes available 


If the only available routes become inoperative caused by a cross~subarea 
link failure then all sessions using that link will be dropped and in the 
case of a permanent failure no recovery is possible. When the link is up 
again the failed sessions have to be reinitiated as described above. 


The failed link may be backed up by a switched line. Such a connection has 
to be established manually and operators on both ends are involved in that 
procedure. This is because there is no special support for switched 
cross~subarea links by the NCP. The failure of a cross-subarea link usu- 
ally creates problems because it 18S an important network component. Even 
backup links often carry some part of the network traffic. So, the failure 
of a cross~subarea link needs high attention by the network operator and 
there is a risk that standard VTAM and NPDA messages will be overlooked in 
the mass of console output. A good solution for that problem is to 
‘Freeze’ and highlight one of the messages that tells about the link fail- 
ure on an NCCF operator screen. To freeze a message means that it will not 
disappear from the screen even if the operator presses the CLEAR key. The 
message only disappears when the operator deletes it or the link 1s up 
again. However, this method needs some customization of NCCF but you can 
find a sample of that ina paper called 'CNM Customizing NCCF, GG24-1554"'. 
For that reason it is not repeated here. 


Automatic restart of a cross~subarea link by VTAM is dependent on where 
the connection is broken. If the connection between the two modems is 
interrupted then the line as defined in VTAM and NCP stays up and only the 
PUs on both sides go to a pending state. They will recover automatically 
as soon as the connection 18S up again. If the connection between the com- 
munication controller and the modem is broken (e.g. data set ready signal 
dropped) then both the line and the PU go to an inactive state on that side 
of the link where the interruption is located. To recover from that state 
_the line and the PU have to be activated either manually or by an automat- 
ically started CLIST. 


Lines and PUs pertinent to a cross~subarea link must be active on both 
ends of the link in order to make the Link operative. Provisions have to 
be made that a reactivation of them is possible without further circum-. 
stances. So, multiple ownership of cross-Subarea links could be advisable 
to make it possible that e.g. a sub-host can activate the link to the cen- 
tral host from his site. 


Reload (re-IPL) of a remote communication controller can become necessary 
following a cross-~subarea link failure. This is the case when the last or 
only link to a stand alone remote 3705 becomes inactive e.g. by a modem 
failure at the remote location. The line as defined in the 3705 becomes 
inactive and has to be reactivated by a VTAM VARY ACT command and for 
that, an active link is needed to the remote NCP. SDLC monitor mode does 
not reactivate a line which has failed due to modem/interface errors. 


A problem may arise if a failed link is up again and you would therefore 
like to use your primary network route instead of the overloaded backup 
route. There 1s no special support by any of the network products to help 
you in such a situation. You have to break the sessions flowing on the 
backup route and reinitiate them in the same way described under headline 
"Routes inoperative but alternate routes available” above. 


NCP FAILURE 


As an NCP is part of a network route, the implications of a route failure 
as described in section "Cross-subarea link failure™ on page 38also apply 
to the failure of an NCP. All sessions which went through or ended in the 
failed NCP are disrupted and must be reestablished. 
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The failure of an NCP can only be recovered by reloading the IBM 3705. 
VTAM will do this automatically if AUTOIPL=YES is specified in the PCCU 
macro instruction of the NCP deck. VTAM will also automatically produce a 
dump of the failed NCP if AUTODMP=YES and DUMPDS=dumpname is specified in 

the PCCU macro definition. 7 


If AUTOIPL=NO, AUTODMP=NO, and DUMPDS=dumpname are specified, the failure | 
of an NCP is distinctly reported on an NCCF screen. NCCF presents the 
VTAM messages © 


POO ISTO095A OPTION TO DUMP ncpname AVAILABLE - REPLY YES OR NO 
POO IST284A OPTION TO RELOAD 3705 ncpname REPLY YES OR NO 


highlighted and they will not disappear from the screen as long as the 
operator has not replied to them. This applies to NCPs loaded over a 
channel or loaded over a cross~subarea link. The same messages with out- 
standing replies go to the system console if NCCF is not up or if there is 
no operator logged on to NCCF who is defined aS a message receiver. 


Although AUTODMP=YES and AUTOIPL=YES seem to be the most comfortable way 
to recover from an NCP failure, it has some disadvantage: 


° The NCP dump dataset may be overwritten by a new dump before the pre- 
ceding dump is printed or saved. 


e In case there is a software problem with the running NCP and the deci- 
sion is made to run a different version of that NCP after the next 
failure, there is no way to tell this to VTAM via VTAM commands (Cas- 
sumed that every NCP version has a unique name). You have to rename 
the NCP deck in the VTAMLST data set so that VTAM cannot find it again 
after failure. 


° In case of some serious hardware or software problems, the system may 
run into a loop, where the NCP is reloaded e.g. every hour. 


e Because it is not so obvious to the network operator that an NCP 
failed, the restart of some sessions, which have been broken by the 
failed NCP, e.g. NCCF to NCCF, may be deferred, if the network opera-~ 
tor has to restart them. 


On the other hand it is advisable and seems to be mandatory to specify 
AUTODMP=YES and AUTOIPL=YES for NCPs channel attached to remote 
sub-hosts. Let us have an example for one reason: There is a central host 
and a remote sub-host and all routes to the sub-host go through one NCP as 
in Figure 16 on page 41. 
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NCCF central 
console operator 
x 


Central NCP14 NCPO04 Sub- 
host 11 . host 01 


Figure 16. Configuration with a remote sub-host 


AUTOIPL=NO, AUTODMP=NO, and DUMPDS=dumpname are specified in all PCCU 
macro definitions of NCP04. If NCP04 goes down the messages to dump and 
reload the NCP do not appear at any of the central operator's consoles. 
The link station controlling the cross-subarea link to the central host is 
also down if the NCP fails. The central host gets messages which tell 
about the route failure but it is not obvious on the central site, that an 
NCP went down. But even if it was obvious, there is no way to reload the 
NCP without intervention from the remote site. 


The remote 3705 with NCP04 could have the Remote Program Load (RPL) fea- 
ture installed, in order to load the NCP across the link. If RPL is active 
on the 3705 by the time NCP04 fails, RPL reports the failure to VTAM via 
the cross-~subarea link which would trigger the messages 


P00 ISTO95A OPTION TO DUMP .... and 
POO IST284A OPTION TO RELOAD .... 


on the central host 11. But this would not solve the above described 
problem. If an IBM 3705 has both RPL and channel attachment capability 
then only one of them can be active at a time. The RPL is activated by 
switching off the channel(s) and vice versa. In the example above, RPL 
must be switched off to.allow sub-host 01 to access the network. 


Another problem that has to be considered is more serious. An interlock 
condition can be created forcing part of the network into a hung state 
after a failure of an NCP which is channel attached to a remote sub-host 
and is defined with. AUTOIPL=NO. The reason for this is that an NCP for 
which messages ISTO095A and IST284A are issued is in an transient state 
which 15 neither active nor inactive. VTAM notifies application programs 
whose LUs are affected by the NCP failure not before the decision is made 
whether the NCP will be reactivated again or stay inactive. The problem 
is, that if NCCF is to display messages ISTO095A and IST284A cross-domain 
at an NCCF console which is disconnected from NCCF due to the NCP failure, 
NCCF is not aware of loosing this terminal. NCCF waits indefinitely to 
one these messages and nobody in the network is notified of the NCP 
ailure. 


That is the main reason that AUTODMP=YES and AUTOIPL=YES have to be speci- 
fied for NCPs channel attached to remote sub-hosts. Here is a sample to 
further clarify the problem: The central operator at host 11 (Figure 16) 
controls VTAM in sub-host 01 through an NCCF to NCCF session. He receives 
all the unsolicited VTAM messages from sub-host 01. If NCP04 fails, NCCF 
in sub-host 01 tries to send the messages 
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POO ISTO95A OPTION TO DUMP .... | and 
P00 IST284A OPTION TO RELOAD .... 


to the central operator at the central host 11 because NCCF is not noti- 
fied that it has already lost the session with the central host's NCCF. 
The messages get stuck in the VTAM buffers because of the NCP04 failure 

sth it could take a little while until any operator realizes what really 
appened. 


ROUTE EXTENSION AND PU FAILURE 


A link from an NCP to a PU Cother than an NCP) is called a route extension. 
Central network operation does not impact the treatment of route extension 
or cluster controller failures by VTAM or CNM tools. Nevertheless, some 
general operation hints are pointed out here in this section. 


The failure of a route extension or a PU which are treated permanent by 
the NCP causes disruption of all sessions using that PU: 


SSCP to PU 
SSCP to LU 
LU to LU 


After the failure is cleared away, the sessions have to be reestablished. 
As stated earlier in this chapter, LU to LU sessions are not automatically 
reactivated by VTAM. For SNA terminals using a non-switched line, automat- 
ic reactivation of the SSCP to PU/LU sessions by VTAM is possible. This 
depends on the component causing the disruption of the sessions. This is 
explained in more detail in the following description in conjunction with 
next figure. | 


local side  -pemote side. 
4 5 | 
1 2 8 LU 
ie 2 eer oe fina [modem [—| ru | ww 
LU 


Figure 17. Sample of an NCP to cluster controller connection 


You can perceive the possibility of an automatic recovery by looking at 
the state of the line and the PU in VTAM after the failure. Automatic 
recovery 15 attempted by VTAM if the line stays active and the PU is ina 
pending state. This is true in cases where the failure is located remote 
of the local modem(1). So, VTAM is able to automatically reestablish SSCP 
to PU/LU sessions in case of a 


e line failure (2) 
° failure of. the remote modem (3) 
e failure of the cluster controller (4) 


e failure of an LU (5) 


This includes the possibility to switch the cluster controller and the 
modem on and off at the remote side and resume operability without opera- 
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tor intervention from the central side. Failures of the modem(1) at the 
NCP side or a failure of the connection between the 3705 and the modem 
however, bring down the line, the PU, and the LUs. It requires that a VTAM 
VARY ACT command for them has to be issued. 


Some software controlled communication controllers like the IBM 8100 
require additional operator intervention in certain cases at the remote 
communication controller side. For instance, if the modem(3) at the PU 
side fails it is treated by the IBM 8100 the same way as a modem(1) failure 
at the local side by VTAM and the NCP. The link as defined in the IBM 8100 
goes down and has to be reactivated by operator commands. 


Cluster controllers on BSC lines like the IBM 3271 are not reactivated by 
VTAM after a permanent failure. VTAM reports a BSC controller failure by 
a whole bunch of messages and leaves the controller in an inactive state. 
Reactivation by means of an NCCF CLIST which is triggered by one of these 
messages is possible and can be helpful in a network with lots of IBM BSC 
327173275. 


OCCF/NCCF FAILURE 


Central operator's control of a sub-host is mainly achieved via NCCF to 
NCCF and NCCF to OCCF sessions. The question is, what can be done when 
OCCF/NCCF goes down or hangs. Is there a possibility to recover from such 
a situation by central operation without manual intervention at the 
sub-host? The answer is yes. Other tools such as TSO and JES2/NJE can be 
used to bring OCCF/NCCF to life again. 1T50 helps to investigate the cur- 
rent state of OCCF/NCCF and JES2/NJE is used to issue JES2 and MVS com- 
mands, e.g. to cancel and restart it. 


If communication from the central host's NCCF to a sub-host's OCCF/NCCF is 
lost because of the sub-host's OCCF/NCCF software problems the central 
operator can still logon to the sub-host's TS0. Within TSO he has two pos- 
sibilities to get information about the state of OCCF/NCCF. The first one 
is the TSO OPER command. To use the OPER command the network operator's 
TSO user identification has to be authorized in the TSO SYSI1.UADS data 
set. Under the OPER command a TSO user can issue a limited set of 0S com- 
mands, e.g. DISPLAY R,LIST or DISPLAY A,LIST . Though he can see whether 
OCCF/NCCF is still active, he cannot cancel or restart it from there. 


The other possibility to look at OCCF/NCCF under TSO is RMFMON. RMFMON is 
a program product which gives the user a lot of information about what is 
going on in every address space on an MVS system. So he can see whether 
aad 1S SWapped out or jis in a loop or cannot get CPU cycles to work 
and so on. 


After the central operator had a look at OCCF/NCCF he might decide to can- 
cel and to restart it. For that he can use the NJE facility of JES2. The 
JES2 SN command is the tool to send JES2 or MVS commands through the net- 
work to other JES2 subsystems. The command carried piggy-back by the $N 
command 15S processed at the receiving host as jit has been entered at the 
receiving host's system console. Here is a sample for what the central 
operator could have entered at his system console to cancel and restart 
OCCF/NCCF at a sub-host: . 


$N,D=N21;CANCEL OCCF 
SN,D=N21;START OCCF,SA=21 


In the above commands, N21 identifies the JES2 subsystem which is to 
receive the commands specified after the semicolon. If the commands are 
not JES2 commands, the receiving JES2 will pass the text to MVS for exe- 
cution, but no attempt is made to return MVS responses. That is the reason 
for using TSO for MVS displays. JES2 commands sent by the $N command for 
execution in another JES2 subsystem will return responses to the sending 
JES2 console. 


Command authority checks are made on all commands received from another 

node. Commands will be ignored if the required authority lacks. To exa- 

cute the above mentioned commands the sending node needs network and sys- 
tem authority in the receiving node. 
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The $N command only works if an application to application session between 
the sending JES2/NJE and the receiving JES2/NJE has been established. So, 
the situation described here is one reason to interconnect the central 
host with its sub-hosts by NJE to NJE sessions during start-up time. Hav- 
‘ing an up and running TSO on every sub-host is another highly recommended 
provision. TSO and NJE are both standard facilities in an MVS/JES2 system. 


CIcS/VS AND _IMS/VS 


Although a break down of a CICS/VS or IMS/VS subsystem its mostly unpleas- 
ant for the end users, the restart does not cause any additional problems 
if CICS/VS or IMS/VS run on a central site controlled sub-host. The same 
procedures used to bring up the subsystems the first time after IPL can be 
normally used to restart them. But of course failure of other components 
may have an effect on the subsystem's operation, for instance what RApPele 


e if: CICS/VS or IMS/VS lose their master terminal 
e if CICS/VS or IMS/VS lose their VTAM 


The loss of a CICS/VS or IMS/VS master terminal does not immediately 
impact the subsystem's end users. Nevertheless, if in such a case the sys~ 
tem console used as an alternate vehicle for master terminal operation is 
at the remote site the subsystems are out of central control. It is neces- 
sary that the central master terminal operator has to couple up to the 
subsystems again. He can do this in several ways: Via TAF or OCCF from an 
ae terminal or from a dedicated terminal. Provisions have to be made to 
allow this. | | 


CICS/VS and IMS/VS are application programs which are able to stay up if 
VTAM goes down. All VTAM network traffic is disabled, therefore CICS/VS or 
IMS/VS close their VTAM ACB and watch for coming events. So, if VTAM comes 
up again communication to the end users via the SNA network can. be 
etch Date, This requires intervention by the master terminal operator. He 
as to issue : . | | 


F cicsid,CSMT OPEN,VTAM in case of CICS/VS or 
R nn,/START DC - in case of IMS/VS 


from a system console (CICS/VS or IMS/VS VTAM only environment assumed). 
It is logical that he cannot enter these commands from a dedicated master 
terminal, because all sessions from VTAM terminals to the subsystems have 
been disrupted. So, for a centralized network and system management the 
central operator needs to have access to the sub-host's system consoles 
and the best way to achieve this is via OCCF. Another method via NJE has 
the disadvantage that it 15 a one way access only. For the above described 
case the operator can transmit the commands to the sub-host but he will 
not get a message back (see "OCCF/NCCF failure” on page 43). 
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CHAPTER 5: PRODUCTS FOR SYSTEM AND NETWORK MANAGEMENT 


NETWORK COMMUNICATIONS CONTROL FACILITY (NCCF) RELEASE 2 


Program Product. Program Number 5735-XX6 
NCCF: General Information, GC27-0429 
NCCF: Installation, $C27-0430 

NCCF: Messages, $C27-0431 

NCCF: Terminal Use, $C27-0432 

NCCF: Customization, S$C27-0433 


NCCF is the key product for communication network management and 1s manda- 
tory for controlling remote sub-hosts from a central site. In the begin- 
ning, it was a tool to ease network operation by transferring, and thus 
concentrating, the network related part of a system console's input and 
output, of one or several systems, to an NCCF terminal. Now with NCCF 
Release 2, more functions are available especially in cooperation with 
other CNM products for which NCCF is the base. NCCF operates as a VTAM or 
TCAM application program in its own address space or partition in:MVS, 
OS/VS1 or DOS/VSE. When used with DOS/VSE systems, the program can also 
operate as a subtask in the VTAM or OCCF partition. NCCF is activated by 
starting it from the system console or by other techniques comparable to 
that. NCCF uses IBM 3270 devices as operator terminals and hardcopy print-— 
ers. To gain access to NCCF an operator must logon and identify himself to 
NCCF. Depending on his level of authorization he may then make use of the 
various functions provided. He may be authorized to control the whole net- 
work and all its systems or be limited to information only type of 
functions. 


Here is an overview of the NCCF functions: 


e Operator control. NCCF operators can enter VTAM and TCAM commands or 
invoke NCCF command lists to modify and display the network configura- 
tion. A terminal logged on to NCCF may also receive unsolicited mes- 
sages indicating an unrequested change of state of a network resource. 


NETWORK COMMUNICATIONS CONTROL FACILITY 02726782 09:20:43 
NCFO1 ISTO89I SWSYS34 TYPE= SW SNA MAJ NODE » ACTIV 
NCFO1 ISTO89I ISTCDRDY TYPE= CDRSC SEGMENT » ACTIV 
NCFO1 ISTO89I N45EF3N TYPE= PU_T4/75 MAJ NODE , ACTIV 
NCFIl P% IST621I RECOVERY SUCCESSFUL FOR NETWORK NODE P14022C 
NCF11 DIS Pi40A0F 
NCF11 DISPLAY NET,ID=P140A0F,E 
NCFIl ISTO75I VTAM DISPLAY - NODE TYPE= PHYSICAL UNIT 
NCF11 ate NAME= P1$O0A0F ,STATUS= ACTIV »DESTRED STATE= 
ACTIV 
NCF11 reat LINE NAME= L140A0 » LINE GROUP= G14$1 » MAJNOD= 
4BF3 
NCF11 IST654I I/70 TRACE = OFF, BUFFER TRACE = OFF 


NCF11 IST355I LOGICAL UNITS: 

NCF1l ISTO80I T14¢0A0F1 ACT-NOSE TI40A0F2 ACT-NOSE . T1I40A0F3 ACT-NOSE 

NCF1l ISTO80I T1Is0A0F4 ACT/S TI40A0F5 ACT-NOSE TI40A0F6 ACT-NOSE 

NCF11 ISTO80I T14¢0A0F?7 ACT-NOSE TIiS¢Q0A0F8 ACT-NOSE 

NCF23 DSTO020I OPERATOR WTCRES2 LOGGED ON FROM TERMINAL H23L3E1 USING 
PROFILECPROFCD ),HCL( ) 


cw Gee wee cee Ge Gee CEES Gene GE Gee Gm Ge Gee we meee WEES Se We ee See ee fe ee Ge UE Gee Gy SE eS ee wen ce eee SEP GP tee Gee mee wee Bee ee Gee een wu Gee eee Eee GE Gem te Wee Ee Se ee Gee ee Ge eR Ge Ee Ge ee ee TEE Gee eee Gee ED Ue GED Gee ee ES ee SE eo oe 


ISTO89I RENATE TYPE= CDRSC SEGMENT 
ISTO89I RILACICS TYPE= CDRSC SEGMENT 


Figure 18. Example of NCCF display: Messages from several domains 
CNCFO01, NCF11, NCF23) are displayed at the NCCF terminal. 
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e Data security. Operator access control is achieved through a 
password-protected logon. Under MVS, the password may be RACF con- 
trolled. 


° Cross-domain communication. An NCCF operator can communicate with 
multiple NCCFs located in different domains simultaneously from one 
terminal. 


° Command lists. Users can code sequences of VTAM, TCAM, NCCF commands 
and NCCF control statements into command lists (CLISTS), which are 
stored ina partitioned data set. This partitioned data set is defined 
in the NCCF start-up JCL procedure and the CLISTsS are invoked by name 
from an NCCF terminal or another CLIST for execution when required. 
Furthermore CLISTs can be named after a TCAM or VTAM message number 
identification. The CLIST is then invoked every time the access method 
would issue this specific message. CLIST control statements and con- 
trol variables are available to control the execution sequence, 
conditionally substitute values at execution time, communicate with 
the operator at execution time, and so on. 


°e Initial commands and CLISTsS. A user specified command or CLIST can be 
automatically executed after NCCF is started, or after an operator's 
logon. 

e Timer-initiated commands and CLISTsS. By use of the NCCF commands AT 
and EVERY, CLISTs and commands can be scheduled for execution at a 
specified time or repetitively at specified intervals of time. 

e Program function key tarloring. The meaning of IBM 3270 PF keys can 
be defined by the installation. So operator keystrokes can be reduced 
by PF key representation of NCCF functions. 


e Span of control. An operator's control can be restricted to a subset 
of the network's resources. 


® Scope of commands. An operator's control can be restricted to a sub- 
set of commands, CLISTs, and operands. 


° Customization. Using NCCF'’s macro services an installation may write 
1tsS own command processors, exit routines, and subtasks. These pro- 
vide additional functions beyond those provided by standard NCCF. 

® Related IBM products. As mentioned earlier NCCF is a program base 
upon which other IBM-supplied programs may be added. The programs 
available today are: 
= NCCF Terminal Access Facility 
~ NPDA 
—  VSE/OCCF and MVS/OCCF 


_ Information/System Release 2 


They are described later in this chapter. 
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NCCF TERMINAL ACCESS FACILITY 


The Terminal Access Facility is an optional feature of NCCF Release 2 
CACF/SVTAM and ACF/VTAME only). Throughout this paper the acronyms 
NCCF/TAF or TAF will be used to make writing and reading easier. 


NCCF/TAF is a terminal simulator program which consists of a collection of 
NCCF command processors and VTAM exits. It is a facility which allows 
communication from an NCCF terminal to 


IMS/VS 1.1.6 and IMS/VS 1.2 

CICS/VS 1.5 

IBM 8100/DPPX through HCF Release 2 
IBM 8100/DPCX through HCF Release 2 


and subsequent releases. Within the following description these subsys~- 
tems are jointly called ‘target systems'. NCCF/TAF may be used with other 
applications, such as NPA, but there is no IBM support for them. 


NCCF/TAF supports two distinct modes of operation: standard control mode 
and full-screen mode. 


° In standard control mode, NCCF/TAF acts in a line-by-line fashion as 
an IBM SNA 3767. An operator using an NCCF terminal can start a ses- 
s10n with one or more target systems. After such a command the opera- 
tor is ready to send and receive commands and messages to and from 
these target systems. Because messages from target systems are inter- 
mixed with each other and with the NCCF output each line has a prefix 
which identifies the related target system. 

NOTE: Standard control mode is not supported for IBM 8100/DPCX. 


° In full-screen mode, NCCF/TAF lets an NCCF operator interact with dis- 
play-oriented applications on CICS/VS, IMS/VS, and through HCF, IBM 
8100/DPPX and IBM 8100/DPCX systems without logging off from NCCF. The 
entire screen is ‘handed over’ to the target system after which the 
entire NCCF screen is owned by the target system application. 


A NCCF operator can establish sessions with multiple target systems 
from one NCCF terminal. Only one target system can use the NCCF/TAF 
display screen at a time, the others are ina disconnected state, but 
sessions are active. While the NCCF operator interacts with these 
full-screen application programs, messages that are intended for that 
operator's screen (such as ACF/VTAM messages) are kept and displayed 
when the operator exits from full-screen mode. The operator may 
optionally choose to have full-screen mode automatically interrupted 
when these messages arrive. The operator can logically 
disconnect/connect his NCCF terminal with each of the established 
sessions without doing a logon/logoff command sequence. 


In full-screen mode NCCF/TAF is defined as only one LU per NCCF opera- 

tor. This implies that the same 'LU name't must be defined in all tar- 

get systems. It also implies that HCF full-screen mode can only 

control one DPPX system without **DROP/XXACQUIRE or logon/logoff pro- 

cess. A unique 'LU name* must be defined for each operator that is to 
*have sessions with the subsystems at the same time. 
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NCCF Operator 
: IBM 
3270 


VTAM MVS IMS/VS 


VTAM | VSE CICS/VS 


------------- Home & 
| | 
| | 
x % 
8100 8100 
DPCX DPPX 


Figure 19. Centralized operation with NCCF/TAF: One NCCF operator 
controlling one IMS/VS, one CICS/VS, one IBM 8100/DPCX, 
and two IBM 8100/DPPX. : 


The operator interactions needed in NCCF/TAF are contained in five NCCF. 
commands (with parameters) and a PA key function used to disconnect froma 
full-screen session. 


BGNSESS start a session with an application 
ENDSESS stop a session with an application 
SENDSESS send a command to an application (standard control mode) 


LISTSESS list status of NCCF/TAF sessions 
DISCONNECT Program attention key Cuser selected) (full-screen mode) 
RTRNSESS reconnect to a session with an application " 


Some of the esunsnda are pretty lengthy if their basic form. With NCCF's 
CLIST facilities, it is possible to make operations simpler and easier to 
use. You may refer to a paper called ‘CNM NCCF Terminal Access Facility, 
GG24-1540' which shows sample CLISTs for use of TAF in conjunction with 
CICS/VS, IMS/VS, HCF, and NPA. 
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NETWORK PROBLEM DETERMINATION APPLICATION (NPDA) VERSION 2 


Program Product. Program Number 5668-983 
NPDA: General Information, G6C34-2061 
NPDA: Installation, $C34-2066 

NPDA: User's Guide, 5034-2063 

NPDA: Recommended Action Guide, $C34-2064 
NPDA: Messages and Codes, 5$5C34-2065 


NPDA assists users in performing problem determination. The program auto- 
matically collects statistical data and information about unusual events 
detected by communications network resources and stores them into a data 
base. For MVS users, NPDA Version 2 extends device error support for 
selected tape, DASD, and printer devices in the network host processor 
system, as well as for the CPU and channels of that system. The NPDA user 
has access, via an NCCF terminal, to the accumulated information which 
includes: 


° Identification of the resource on which a specific alert, statistic, 
or event has occurred. 


e Description of alerts and events. 


e Probable cause of alerts and events based on an analysis of the 
recorded data. 


° Recommended actions that the user may follow to correct or override 
the problems described in the alert or event. 


e Accumulated statistics about temporary, or recoverable, error events 
that may be used to help analyze performance degradation and intermit- 
tent failures. 


NPDA operates as a series of command processors under NCCF in the NCCF 
address space or partition. Collecting data and displaying data are inde- 
pendent of each other and are therefore initiated at different times. The 
data collection is an automatically process which is started as soon as 
NPDA/NCCF is initialized. 


NETWORK COMMUNICATIONS CONTROL FACILITY 02726782 09:324:342 A 
NPDA-40A * TOTAL EVENTS X 


* FOR SELECTED RESOURCE X 


KKK KKH KKK HKKKKKKN RESOURCE XXX KKXRKKKRK KKK KK 
TYPE RESNAME TOTAL FROM 


COMC 
COMCc 
COMC 
COMC 
COMC 
8100 
8100 
8100 
8100 


S 
C 
( 
C 
( 
( 
( 
C 
C 
¢ 


Oo OOnAUDWHE 
Nd Ne Ns es es Os Os a es 


ENTER "ST'CSTAT), 


227 KX 


Figure 20. 


NOS3F3M 
NI4BF3™ 
NI4BF3N 
N245FNN 
N45EF3N 
DOM2 
DOM3 
BABE 
TTE6 


02/723 
00700 
02/17 
02/22 
02/19 
00/700 
00700 


00700 


00700 


OR SEL# CATTACHED), OR SEL# PLUS 


Example of NPDA Total Events Display: 


total 
information, 


Chapter 5: Products for system and network management 


number of events. 
e.g. 


The user 


to a display which 
recent events for a specific component (see next figure). 


02/725 
02/725 
02/26 
02/26 
02/23 
02/24 
02/24 
02/725 
02/24 


M'CMOST RECENT) 


This display shows 
is guided to other 
shows the most 


49 


NETWORK COMMUNICATIONS CONTROL FACILITY 02726782 09:31:59 A 
NPDA-41A * MOST RECENT EVENTS PAGE 1 OF 1 
* FOR SELECTED RESOURCE xX | 


DOMAIN TYPE RESNAME TYPE RESNAME TYPE RESNAME 
NCF1l COMC N245FNN LINE L24020 CTRL P24020E 
DATE/TIME EVENT DESCRIPTION: PROBABLE CAUSE ETYP ACT 

02/26 : COMMUNICATION ERR: DEVICE/REMOTE MODEM INTERFACE PERM qd: 
02/725 : COMMUNICATION ERR: DEVICE/REMOTE MODEM INTERFACE PERM 
02725 a1. COMMUNICATION ERR: DEVICE/REMOTE MODEM INTERFACE PERM 
02725 : COMMUNICATION ERR: DEVICE/REMOTE MODEM INTERFACE PERM 
02/24 : POWER OFF DETECTED: DEVICE OFF/DEVICE | — PERM 
02724 : DSR ON CHECK:LOCAL MODEM OFF/LOCAL MODEM PERM 
02/724 ; POWER OFF DETECTED:DEVICE OFF/DEVICE PERM 
02/23 : POWER OFF DETECTED:DEVICE OFF/DEVICE PERM 
02/23 : POWER OFF DETECTED:DEVICE OFF/DEVICE PERM 
02/723 ; REMOTE MODEM-NO RESPONSE:MODEM OFF/LINE/MODEM PERM 
02/723 : COMMUNICATION ERR: DEVICE/REMOTE MODEM INTERFACE PERM 


ENTER 'ST'(STAT), OR SEL# (ACTION), OR SEL# PLUS ' D'(DETAIL) OR ' P'(PROBLEM) 


( 
C 
( 
C 
( 
( 
( 
( 
C 


1 
2 
3 
A 
5 
6 
7 
8 
9 
10 
11 


) 
) 
) 
) 
) 
) 
) 
) 
) 
) 
) 


222 RX 
Figure 21. Example of NPDA Most Recent Events Display 


NPDA data can be displayed on an NCCF terminal only. The terminal is 
shared between NPDA and NCCF and no separate logon is required. NPDA com- 
mands and other commands can be entered in any sequence. A PF key can be 
assigned to NPDA which is then used as the NPDA enter key to allow NCCF to 
distinguish between NPDA commands and other input. NPDA_ produces 
full-screen displays. Output produced by NCCF will partly or completely 
overlay NPDA output. 


The NPDA data the user can view is classified as event data if it relates 
to permanent errors, or Statistical data if it relates to temporary errors 
and traffic. Included in the event data are records created by NPDA from 
analysis of statistical data which indicate that user specified thresh- 
olds have been exceeded. The alert data is a subset of the event data, 
which requires immediate attention. 


By issuing the NCCF NPDA command the first time (pressing for instance the 
NPDA assigned PF key) the user gets the NPDA menu display. From that menu 
he selects a data type (alert, event, or statistics) and then may either 
step through a procedure that pinpoints a failing resource or, if he is 
already aware of which resource is failing, go directly to data about that 
resource. 


In addition to having access to the information in the user's home domain, 
he can also view SNA data in another domain if an NCCF to NCCF 
cross-domain session is in progress and if a peer NPDA is operating in the 
target domain. 


The recording of data on the data base and the display of the data can be 
controlled by NPDA filter commands. 


NPDA also interfaces with INFO/Management for automated problem entry 
into the INFO/Management data base. 
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MVS OPERATOR COMMUNICATIONS CONTROL FACILITY (MVS/OCCE } 


Program Product. Program Number 5665-288 
MVS/OCCF: General Information Manual, GC24-5225 


MVS/OCCF allows one or more remote MVS/SP-JES2 systems to be operated from 
a host and is also designed for simplifying MVS/SP-JES2 console operation. 
Furthermore it supports the Remote Operator Console Facility (ROCF) a 
hardware function of IBM 4300 processors. Here is a brief description of 
MVS/OCCF and its functions: 


MVS/OCCF is activated by starting the OCCF task either from an MVS console 
or by other techniques comparable to that. NCCF or NPDA/NCCF run as sub- 
tasks of MVS/OCCF if they all run on the same processor. 


° Remote operations / Message routing. An operator on an NCCF terminal 
can logon to MVS/OCCF located either in the same domain or ina remote 
domain. He may then enter MVS, VTAM, TCAM, and JES2 Commands from that 
NCCF terminal. He may also get all the messages (depending on MVS/OCCF 
start-up parameters) which normally go to the MVS console. The NCCF 
screen is logically made an MVS console. Although only one NCCF opera- 
tor/terminal may communicate with one MVS/OCCF on a specific host, an 
NCCF terminal can communicate with multiple MVS/OCCFs on different 
hosts. | 


° ROCF support. The ROCF support allows the user to IML/IPL and operate 
remote IBM 4300 processors through a switched BSC 1200 baud connection 
from an OCCF/NCCF terminal. It gives the OCCF/NCCF user the ability to 
access a remote IBM 4300 host independent of the availability of VTAM 
on that system. . 


° MVS/OCCF command lists (CLISTS). Users can code sequences of MVS, 
VTAM, TCAM, JES2 commands and MVS/OCCF control statements into com- 
mand lists (CLISTs), which are stored ina partitioned data set. This 
partitioned data set is defined in the MVS/OCCF start-up JCL procedure 
and the CLISTs are invoked by name from an MVS console or another 
CLIST for execution when required. They can of course also be invoked 
from an NCCF terminal from which a session with OCCF is in progress. 
MVS/OCCF CLISTs are distinguished from MVS and JES2 commands by the 
first character. This character is defined by the user as an MVS/OCCF 
initialization parameter (CThroughout this paper a % character is used 
to designate an MVS/OCCF CLIST). MVS/OCCF CLIST logic and MVS/OCCF 
control statements supply functions like 


= substitution of variable parameters at CLIST execution time. 


= conditional flow and execution of the commands by means of "IF 
- GOTO ...™" logic. 


ss delay processing of commands in a CLIST at execution time for a 
specified number of seconds. | 


= WTO 


® Automatic message reply. By specifying message replies ina so called 
message action table MVS/OCCF will reply to a specific message id with 
a specific response. 


° DISPLAY facility. The content of MVS/OCCF CLISTs can be displayed on 
the MVS console. By concatenating JCL procedure libraries, NCCF CLIST 
libraries, etc. to the MVS/OCCF CLIST library all of the procedures 
specified in these libraries can be displayed on the MVS console. 
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MVS SECONDARY OPERATOR FACILITY (SOF) 


Field Developed Program. Program Number 5798-CRE 
SOF: Availability Notice, GB21-2179 | | 
SOF: Program Description/Operations Manual, SB21-2180 


SOF is designed to eliminate or reduce operator errors by allowing MVS 


console operation with simplified commands, and automatic command or job | 


submission. There is a CLIST capability in SOF which is very much similar 
to the one provided by MVS/OCCF. However, MVS/OCCF lacks some of the SOF . 
functions and these are marked with X*) in the following description of SOF 
functions: | 


e SOF command lists (CLISTsS). Users can code sequences of MVS, VTAM, 
TCAM, JES2 commands and SOF control statements into command lists 
(CLISTs), which are stored ina partitioned data set. This partitioned 
data set is defined in the SOF start-up JCL procedure and the CLISTs 
are invoked by name from an MVS console, from another CLIST, or at 
*¥)JSOF initialization time for execution when required. SOF CLISTs are 
distinguished from MVS and JES2 commands by a / as the first 
character. : | s 


= substitution of variable parameters at CLIST execution time. 


— conditional flow and execution of the commands by means of "IF 
. GOTO ..." logic. 


= delay further processing of commands in a CLIST for a specified 
number of seconds. , 


°  *)Time of Day Event Scheduler. This facility allows the automation of 
job, command or SOF CLIST submission at a user specified date and 
time. | 


° *¥)Initial Clist execution. This facility allows the execution of a 
clist at initialization of SOF. 


e *JJES internal reader interface. SOF CLISTs can be routed to the JES 
internal reader. This function makes it possible to submit MVS jobs 
from an MVS console or submit them.at a user specified time. 


e DISPLAY facility. The content of SOF CLISTs can be displayed on the 
MVS console. By concatenating JCL procedure libraries, NCCF CLIST 
libraries, etc. to the SOF CLIST library all of the procedures speci- 
fied in these libraries can be displayed on the MVS console. 


SOF itself is activated by starting the SOF task either from an MVS con- 
sole or by other techniques comparable to that. SOF 1s a product that 
works independent of other communication network management tools, and it 
has no NCCF interface. SOF CLISTs can be invoked from an NCCF terminal 
only through OCCF. Although some of the SOF functions overlap with 
MVS/OCCF functions SOF still seems to be a valuable tool e.g. to 


e automate the IPL procedure and the MVS and network activation toa 
certain degree either on the remote or the central site. 


° check network components at user defined intervals and restart them if 
necessary or alert the network operator. 


° reduce operator skills at the remote site by means of predefined oper- 
ating procedures. ) 


® start and stop applications, maintenance jobs, backup jobs etc. ata 
user specified, predefined date and time. 


° Used to complement MVS/OCCF. It 1s not dependent on teleprocessing 
access method and can be used to monitor MVS/OCCF. 
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NETWORK PERFORMANCE ANALYSER (NPA) 


Field Developed Program. Program Number 5798-CZR, 5798-CZT 
NPA: Availability Notice, GB21-2478 
NPA: Program Description/Operations Manual, S$B21-2479 


The Network Performance Analyzer (NPA) monitors, collects, and displays 
network performance data which may be used for: 


e¢ Highlighting causes of performance degradation 
° Tuning networks for better performance 
e Capacity planning for future growth 


The data gathered by NPA is available for online and offline evaluation. 
The FDP comprises two products, a host application program (Number 
5798-CZR) and an extension to the NCP (Program number 5798-CZT). They run 
under OS/VS1 or MVS, with VTAM and/or TCAM. NPA has a companion FDP (Net- 
work Performance Analysis Reporting System, NETPARS, program number 
5798-CZX) which creates structured reports from NPA log output. 


Highlights of NPA functions: 


e Collection of 3705, NCP, message traffic, and line control statis- 
tical data by user criteria. In a multi-~system network, NPA can col- 
lect data from every NCP with which it can communicate. 


° Dynamically changing immediate display of statistics based on the 
collected data. 


e Review display of previously collected statistics. 


° Data of particular significance may be monitored against user speci- 
fied criteria and exceptions reported as they occur. 


e Collection, display, and monitoring can automatically start after NPA 
initialization or at a specified time of day. 


13:45:26 FOR RESOURCE L14022 THE ERRCNTS VALUE OF 17 WAS ABOVE THE 
MONITOR LIMIT OF 10 
% % NETWORK PERFORMANCE ANALYZER ® UNLOCKED 
13:44:56 DISPLAY RESPONSE 02/25/82 
NAME TOT MIN.SC OUTQ MNSG/MN CH/S PLN% SLN% PLL/M “NEG ERRS REMSG RECHR 
N14¢BF3N NCP 00:4 % CCU UTIL= 16 % IN SLD= 00 CHHLDQ= 2 CHINTQ= 1 
NCP BUFFERS FREE=1898 HIGH=1907 LOW=1897 MAX=1698 SLD LIMIT= 212 
L14024 LINK : 00 
L14026 LINK : 16 176 02 600 
L14028 : 282 03 600 
L1402C : 248 03 600 
L14040 ; 240 15 600 
Li40A5 : 120 10 600 
L140A0 : Do< 15 289 
P140A0F : 132 289 
T140A0F1 
TI40A0F2 
TIS¢0A0F3 
TIS40A0F4 
TIS0A0F5 
T140A0F6 


Figure 22. Example of NPA display: The upper two lines show a 
monitor message. The other data is displayed in response 
to one or several START DISPLAY commands. The display is 
updated at user specified time intervals. 
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NPA is activated by starting it either from a system console or by other | 
techniques comparable to that. In order to use the online facilities of 

NPA the user has to logon to NPA from a 3270 screen. He can then enter 
commands and receive output from NPA such as statistic display or monitor 
messages. Using NPA is quite straightforward, since there are only a few 
NPA commands: . 


° START/STOP COLLECT tells NPA to begin collecting performance data on 
one or more network resources Cimmediately or at a future time). | 


° START/STOP DISPLAY initiates collection and display of data (the data 
displayed is changed at periodic intervals). 


@ START/STOP MONITOR is’ similar to Display, but accepts a range of 
threshold values and if the measured parameter falls outside of the 
range, a message is displayed in the top two lines of the screen. 


e REVIEW causes the display of interval and total records for a given 
- resource. | | 


e- STATUS shows the network | resources for which START 
COLLECT/DISPLAY/MONITOR commands have been issued. 


Note: NPA does not support terminals that have been dynamically reconfig- 
ured. : | | 
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HOST COMMAND FACILITY (CHCF) VERSION 2 


Program Product. Program Number 5668-985 
HCF: General Information Manual, GC27-0453 
HCF: User's Guide, $C27-0455 


HCF is a VTAM or TCAM application program for MVS and DOS/VSE, which 
allows a System/370 terminal user to access and control a connected IBM 
8100/DPPX or IBM 8100/DPCX subsystem. HCF is essential when controlling 
IBM 8100 systems from an MVS or DOS/VSE host. 


The user's terminal logically belongs to the IBM 8100 system, though the 
System/’370 user has the ability to 


e interactively operate and control IBM 8100 systems 

° use all operation and service facilities available in an IBM 8100 sys- 
tem, except those requiring operator intervention, such as mounting a 
tape 


e use any DPPX or DPCX application program in an IBM 8100 system 


e perform problem determination and error diagnosis tasks that do not 
require manual intervention on the IBM 8100 system . 


HCF supports IBM 3270 displays and IBM 3767 terminals as workstations. HCF 
allows several users to access the same DPPX or DPCX subsystem from dif- 
ferent terminals at the same time. Each user, however, may access only one 
subsystem through HCF at a time. HCF may also be used through TAF from an 
NCCF terminal (see "NCCF Terminal Access Facility" on page 47 for more 
information). 


Using HCF is pretty simple. First, a user has to logon to the VTAM appli- 
cation HCF. After that, the HCF commands 


X¥ACQUIRE and *xXDROP 


are used to connect/disconnect to/from a specific application in a speci f- 
ic IBM 8100 system. 
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INFORMATION/SYSTEMCINFO/SYSTEM) RELEASE 2 


Program Product. Program Number 5735-025 | 

INFO/System: General and Pre-Installation Information Manual, GC34&-2027 
INFO/System: Installation and Customization, 5C34-2029 

INFO/System: Messages and Codes, $C34-2043 

INFO/Management: User's Guide, $C34-2031 

INFO/Management: Scenarios and Panel Flow, $C34-2045 


INFO/System contains three components which are nearly independent: 
INFO/MVS, INFO/Management, and INFO/Access. INFO/MVS and INFO/Access 
allow access to IBM supplied data bases which contain technical informa- 
tion pertinent to the MVS environment. This information is mainly used by 
system programmers for software problem resolution. 


The part of INFO/System most useful in the operation environment is 
INFO/Management. The facilities supplied by INFO/Management provide for 
manageability and control of the data processing operation in the areas 
of: . 


° Problem Management 
° Change Management 
e Configuration Management 


With INFO/Management, the user creates, updates, displays, and prints 
records that document his installation's data processing problems, chang- 
es, and system components. These records are stored in the INFO/Management 
data base and can be searched according to the user's criteria. For exam- 
ple, he may search for all open problems that have occurred at a partic~- 
ular location, all changes scheduled for a specific date, the names of 
personnel responsible for servicing a component, or relationships between 
certain problems, changes, and system components. 


INFO/Management is essentially a panel-driven system, whereby the user is 
prompted for the information necessary to create, retrieve, and update 
records. In addition to the panels which enables the user to create, 
search, and display records, a set of subcommands are used to invoke spe- 
cial functions and to manipulate the data collected by the panels. 


The problem management part is connected to NPDA. Initial problem infor- 
mation can be extracted from the NPDA data base and copied to the 
INFO/Management data base by entering a simple command under NPDA. 


INFO/System operates as a command processor under. 1750 or NCCF running on 
MVS. For DOS/VSE users, a CICS based FDP called Account Network Management 
Program CANMP) provides functions similar to INFO/Management. 


For the best use of system resources, INFO/SYSTEM should be executed under 


a TSO session and only the NPDA interface used under NCCF. The TSO session 
can be established via the TAF feature of NCCF. 
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APPENDIX A. CLIST EXAMPLES 


NCCF CLIST: HELP 


&CONTROL ERR 

&A = &1 

&IF .&A EQ . &THEN &GOTO -HELP 
&IF &A EQ HELP &THEN &GOTO -HELP 
&IF &A EQ ? &THEN &GOTO -HELP 


AUTO1 NO 

&B = &SUBSTR &A 1 § 

CLR1 . <=== The CLR1 command is described in 
HELP&B &2 "CNM Customizing NCCF, GG24-1554' 
&IF &RETCODE EQ 0 &THEN &EXIT 

&A ? 

& EXIT 

&IF &RETCODE EQ 0 &THEN &EXIT 

-HELP 

CLR1 


&BEGNRITE -END 
HE HE EEE IE DEI IK IE IE HEE HE DE DE DE DK DK HK DE DE IE HE HE IE HC DE DE DE DE DE HE HE HE HEHE HE HE DED DE DEK DE HE DE HE HEE HE EK HE HE EE EHH 


* HELP0000 HELP FUNCTION X 
3 ¥ 
* SELECT ONE OF THE FOLLOWING COMMANDS FOR SPECIFIC HELP: % 
% x 
x COMMAND AREA WHERE IT IS APPLIED x 
Keene nnn eee eee ee 7 
* CLISTS To show installed CLISTS for VTAM/NCCFE % 
* NCCF To show the format of NCCF commands | | x 
* HELPOCCF To show the format of OCCF commands % 
* HELPTAF To show the format of TAF commands ¥ 
* NPDA HELP To show how to use NPDA % 
* SENSE To show the meaning of sense codes % 
* STCSTATUS) To determine VTAM status modifiers % 
* INFO To show how to use INFO/MANAGEMENT ¥ 
* DEMOS To demonstrate FULL PANEL | X 
* TOOLS To show which problem determination tools ¥ 
* HELPPFK To show the use of programmed functions keys % 
HE HEE DE DE HE HE HK HE HE HE HE HE EE HE EE HE DE EK EK HK EE DE HE EE EE EE EE EE EE EE HE EE EEK OE IE HEE EE EK EE EE EK 
-END 

& EXIT 


CLISTS to activate network nodes 


SOF CLIST ACT is invoked by entering: /ACT 


&0S OPT TE ? U 

&* ISSUES A VTAM VARY ACT 

&* FIRST PARM IS ID OF RESOURCE 

&* SECOND PARM IS MODIFIER (DEFAULT IS U) 

&IF &£0 EQ ? GOTO &-HELP 

&WTO V NET,ACT,ID=&0,SCOPE=&1 

V NET,ACT,ID=&0,SCOPE=&1 

& EXIT 

&-HELP 

&WTS Correct form is ACT nodename<,ALL|COMP|ONLY|U> 
eee Where the SCOPE option is ALL, COMP, ONLY or UCdefault). 
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MVS/OCCF CLIST ACT is invoked by entering: %ACT .... 


&DEF OPT TA ? U 

&. ISSUES A VTAM VARY ACT 

&. FIRST PARM IS ID OF RESOURCE 

&. SECOND PARM IS MODIFIER (DEFAULT IS U) 

IF &1 EQ ? &GOTO -HELP 

&SWRITE V NET,ACT,ID=&1,SCOPE=&2 

V NET,ACT,ID=&1,SCOPE=&2 

& EXIT 

~HELP 

&WRITE Correct form is ACT nodename<,ALL|COMP]ONLY]|U> 
&WRITE Where the SCOPE option is ALL, COMP, ONLY or UCdefault). 
& EXIT | 


NCCF CLIST ACT is invoked by entering: ACT .... 


&CONTROL ERR | 

* VARY NET,ACT,ID=CNODE NAME),SCOPE=C(COMP,ONLY,ALL,U) 
&IF .&1 EQ . &THEN &GOTO -TELL3 
&IF .&1 EQ .? &THEN &GOTO -TELL2 
&A = &1 

&B = &2 

&GOTO -TELL4 

~TELL2 | 

HELPACT 

&EXIT 

&GOTO -TELL 

~TELL3 

HELPACTO 

&BEGNRITE -ENDI 

% 


* to continue enter GO nodename,<scope> (to activate resource) 
¥ or CANCEL | , (to cancel) 

HEH HEE HEE IEE EEE IE IEE EE EEE EK IEEE EE EEE EE HEE HE HEE EEE KKK EKER KK 
-END1 7 | 
&PAUSE VARS &A &B 

-TELLS 

&SCOPE = &B 

&IF .&SCOPE EQ . &THEN &SCOPE = U 

&IF &SCOPE EQ A &THEN &SCOPE = ALL 

SIF &SCOPE EQ ALL &THEN &GOTO -GO 

&IF &SCOPE EQ C &THEN &SCOPE = COMP 

SIF &SCOPE EQ COMP &THEN &GOTO ~-GO 

&IF &SCOPE EQ 0 &THEN &SCOPE = ONLY 

&IF &SCOPE EQ ONLY &THEN &GOTO -GO 

&IF &SCOPE EQ U &THEN &GOTO -GO 

CLR1 | 

&WRITE Specification error in the scope operand ™ &SCOPE " 

HELPACT 

~TELL 

-END2 

& EXIT 

-GO 

&WRITE VARY NET,ACT,ID=&A,SCOPE=&SCOPE 

VARY NET,ACT,ID=&A,SCOPE=&SCOPE 


Member: HELPACT CNCCF) 


&CONTROL ERR 

HELPACTO 

&BEGWRITE -END1 

*® Enter ACT without parms for prompted operation 

HH HE HE HHH DEH HE IE DE HEH DE OE HED HE HE KE HEHE DE OE EE HE IE EE HK OE IE HK HE KE HE OK DE IE KDE EE HEE HE KKH 
-ENDI 

& EXIT 
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Member: HELPACTO C(NCCF) 


&CONTROL ERR 
CLR1 
&BEGWRITE -END1 


£24.20, 0.0,5,2,5,2,0,5,0,5,0,0,5,2,0,55,9,5,8,5,0,.0,5,0,9.8,5,0, 008.8. tet tat ttt tatetatatatatat tats tatatatet stata tate tte te ta: 


KK KK K KK OK OK OK OK OK OK OM 


* HELPACTO ACT CVTAM CLIST) TUTORIAL 
This CLIST should be invoked to activate VTAM nodes. 
Correct formats: 
ACT nodename 
ACT nodename,scope 
nodename Crequired) is the name VTAM identifies the node 
to be activated 
scope Coptional) ALL (CA) 
COMP (C) 
ONLY (CO) 
UCdefault) 
-ENDI 
& EXIT 


MVS/OCCF CLIST: OS MOUNT command 


Member: M 


&DEF OPT TA DEFAULT DEFAULT PRIVATE 

&IF &2 EQ DEFAULT &GOTO -ERR .MUST PROVIDE 2 PARMS 

&IF &C GT 3 &GOTO -ERR .MAXIMUM OF 3 PARMS 

V &1,ONLINE 

MOUNT &1,VOL=CSL,&2) ,USE=&3 ~SUBMITTED THROUGH OCCF 
&EXIT .WE'RE DONE NOW 

-~ERR .TOO MANY OR NOT ENOUGH PARMS 

&WRITE MOUNT PARAMETERS ARE: UNIT SERIAL USAGE 

&WRITE UNIT AND SERIAL ARE REQUIRED 

&WRITE USAGE DEFAULTS TO PRIVATE, MAY BE STORAGE OR PUBLIC 


MVS/OCCF CLIST: /STARTGTF command 


Member: STARTGTF 


&DEF OPT TN A 

&. STARTGTF PROCEDURE 

&. ENTER /STARTGTF TO AUTOSTART GTF 

&. NO OPERATOR ACTION IS REQUIRED. 

&IF &1 EQ ? &GOTO -HELP 

> GTFDISK.GTF .SUBMITTED BY SOF 

& EXIT 

-HELP 

&WRITE STARTGTF PROCEDURE 

&WRITE ENTER /STARTGTF TO AUTOSTART GTF 

&WRITE NO OPERATOR ACTION IS REQUIRED. 

teres NCCF WILL BE NOTIFIED WHEN GTF HAS STARTED. 
XIT 


Appendix A. CLIST examples 


59 


MVS/OCCF CLIST: /STOPGTF command 


Member: STOPGTF 


&DEF OPT TN O01 

&. STOPGTF PROCEDURE 

&IF &1 EQ ? GOTO &-HELP 

P GTF 

&EXIT 

-HELP 

&WRITE ZSTOPGTF ISSUES A STOP AND NOTIFIES NCCF 
&WRITE THAT A GTF SHUTDOWN HAS BEEN REQUESTED. 
& EXIT 


NCCF CLIST to reactivate selected PUs after msg ISTI69I1 


Member: IST169I 
&CONTROL ERR 


&WRITE *IST1I69I &1 &2 &3 &4 &5 &6 &7 &B &9 &10 &11 &12 &13 &14 &15 &16 
% | 

* IST1691 DISCONNECTION CAUSED VARY INACT FOR PU = xxxxxxxx 

% 


&IF && NE P14022A &THEN &GOTO -END 
VARY NET,ACT,ID=&8 
2 | 


-END 
& EXIT 


CLISTsS for system monitoring 


NCCF CLIST: MONITOR 
&CONTROL ERR 


MVS “SYSMON &l1 
& EXIT 


OCCF CLIST: SYSMON 
&DEF OPT TE il 


&. THIS PROCEDURE IS EXECUTED BY THE SAMPLE TOD EVENTS. 


&IF &1 EQ ? &GOTO -HELP 
&WRITE NETWORK CHECK SA&l 


00010000 


00020000 
00070000 
00090000 
00120000 
00200000 
00210000 
00220000 
00230000 


“STARTNJE &1 <=== see "MVS/OCCF CLIST to start NJE" on page 66. 


-~HELP 
“4QSHOW SYSMON 
&EXIT 
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NCCF CLISTs to tailor VTAM messages 


Member: ISTO077I 


&CONTROL ERR 

* ISTO77I SIO=nnnnnnnn CUA=c 

* NOTE THAT ARITHMETIC VARIABLES REMOVE LEADING ZEROS 
* NOTE YOU CANNOT SUBSTR &l 


&SIO = &1 

&SIO = &SUBSTR &SIO 5 
&SIO = &SIO + 0 

&CUA = &2 

&CUA = &SUBSTR &CUA 5 


&BEGNWRITE SUB -END2 

ISTO77I Start I/O count = &SIO ; System address = &CUA 
~END2 

& EXIT 


Member: IST097I 
&CONTROL ERR 


*XISTO97I DISPLAY ACCEPTED SUPPRESSED 
&EXIT 


Member: IST241I 
&CONTROL ERR 
se NCPSTOR COMMAND COMPLETE SUPPRESS IT 


LARGE a CL TS ATT AS TST TSE ES Ee TSS TST eS Ts Cs USPS SESE STSTSSUISWEIRA SNES 
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NCCF CLIST to ACQUIRE an NCP 


 &CONTROL ERR 


&IF .&1 EQ &THEN &GOTO -TELL 

&SA = &1 

&SCOPE = &2 

&IF .&SCOPE EQ. &THEN &SCOPE = U | 
&IF &SCOPE EQ A &THEN &SCOPE = ALL 
&IF &SCOPE EQ ALL &THEN &GOTO -GO 
&IF &SCOPE EQ C &THEN &SCOPE = COMP 
&IF &SCOPE EQ COMP &THEN &GOTO -GO 

&IF &SCOPE EQ 0 &THEN &SCOPE = ONLY 
&IF &SCOPE EQ ONLY &THEN &GOTO -GO 

&IF &SCOPE EQ U &THEN &GOTO -GO 
&GOTO -TELL 3 7 
-GO 


IF &SA EQ 4& &THEN &GOTO -GOl 
&IF &SA EQ 14 &THEN &GOTO -GO2 
&IF &SA EQ 24 &THEN &GOTO -GO3 


&WRITE 
~TELL 

&WRITE 
&WRITE 


SPECIFICATION ERROR: 


HE HE HE HEE HE HE HE HE HE DE DE DE EK IE KOK OK DEK EK HK HK HK HK YE HEH DOE EE HE EK HE HEE HE EE EEE KH 
* GRAB ACQUIRES THE NCP'S WITH THE SUBAREA'S 4,14 OR 24 


% 
&WRITE THEN WAITS FOR AN OPERATOR "GO" TO CONTINUE * 
&WRITE TAKEOVER OF THE MINOR NODE RESOURCES iS 
&WRITE X THE FIRST OPERAND IS THE SUBAREA NUMBER OF THE NCP % 
&WRITE THE SECOND OPERAND IS AJALLICICOMP|O[ONLY[U DEFAULT X 
&WRITE x THE NCPNAMES ARE NO43F35,N14BF35,N245F35 x 
KIRT TE 3 HH EEK EE EE EE EE KK HE EEE EE EEE EE DE EE EE EE EEE EEE EK EK EEK KH 
~GOl | 7 
&éWRITE VARY NET,ACQ, ID=N043F35,SCOPE=&SCOPE,ACT 


VARY NET,ACQ, ID=N043F35,SCOPE=&SCOPE,ACT 


&WRITE. 


&WRITE 
&WRITE 
PAUSE 

&WRITE 
&WRITE 
&WRITE 


HE HK HH HK HK HK HK KH HK EK KK HR HE EK EK EEE EK EK EERE 


* REPLY "GO" IF TAKE OVER COMPLETED | af 
HEE HEHE HEHE HK EEE DE HE EE EEK KK KKK KK KK KK KKK 


es ATs ahaa eS a 


* REPLY "GO" ACCEPTED 
29631 00GO 00 00E OE ISODUEHGHS DI GOBOOG: 


VARY NET,ACQ,ID=P040A0A,ACT,SCOPE=&SCOPE 


& EXIT 
~GO02 


etc. 


&WRITE VARY NET, ACQ, ID=N14BF35,SCOPE=&SCOPE, ACT 
VARY NET,ACQ,ID=N14BF35,SCOPE= &SCOPE, ACT 


KLIR LT TE 456 6 EK EE HK EE EE EE EE KKK KKK HK 
&WRITE * REPLY "GO" IF TAKE OVER COMPLETED ¥ 
SINR TE 39 6 6 HE EK EE EEK EK KE KK EI KOE KK EHH KH 
PAUSE 7 
SUR LTE 6 KKK KK KEKE EE EE EEE EE EE EK KK KKK KK 
&WRITE * REPLY "GO" ACCEPTED % 
SIR LTE 34 36 EE EEK EEE EEK EE EEE EEE KKK KEM 
VARY NET,ACQ,ID=P140A0A,ACT,SCOPE=&SCOPE 

etc. 
& EXIT 
-GO3 
&gWRITE VARY NET,ACQ,ID=N245F35,S5COPE=&SCOPE,ACT 


VARY NET,ACQ,ID=N245F35,SCOPE=&SCOPE, ACT 


&WRITE 
&WRITE 
&WRITE 
PAUSE 

&WRITE 
&WRITE 
&WRITE 


SoS 2.2.2. 8,0,9,0,0,0,0,0,0,0, 0,0, 0,5,9,0,5,0,0,0,0,0,0,0,0,9,0, 98,0, 0,0, 0,5, 0, 0,5, 


* REPLY "GO" IF TAKE OVER COMPLETED x 
HE HE HE 3 3 HE EH 3 HE HE EE EK DK OE EE OE EK EK EEE KK 


HH HK HK HEH HK HH HH HK HK HK HE HE HK HH HK HX 


x REPLY "GO" ACCEPTED as 
3 HEHEHE HEE DE HEE DE IK DE DE DE DED KEK IE EEE KK OK EK KK EK EK HE 


VARY NET,ACQ,ID=P240A0A,ACT,SCOPE=&SCOPE 


& EXIT 


etc. 
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APPENDIX B. 


SYSTEM AND NETWORK ACTIVATION: 


PARMLIB member COMMNDxx 


SAMPLE DEFINITIONS 


COM="SEND 
COM="SEND 
COM="SEND 
COM="SEND 
COM="SEND 
COM="SEND 
COM="SEND 
COM='SEND 


FE HE HE HK DE EEK IE EEE DE EEE EEE EEE EK KKM KKHKXK! ,RBRDCST' 
13K 9G EEE DEE KE DE EE DE EEE EEE EEE KKK KRM KKKK!  BRDCST' 


"* *¥",BRDCST! 
"XX MVS OPERATING SYSTEM *¥', BRDCST' 
1 RX SERVICE LEVEL IS 8206 **¥",BRDCST' 
"x ¥¥',BRDCST' 


F 5K DE HE HEE IE HE HEE EE IE IEE IE DE SE IEE EEE EEE EEE MK MKKKK! BRDCST! 
V 3G EEE IEE IE IEE HE IK HE HE HE EK EE EE KE EK EE EEE KK KK!  BRDCST! 


COM='CD SET,SDUMP=CALLPSA,NUC,SQA,LSQA,RGN,LPA,TRT,»,SWA,CSA,SUM),Q=YES' 
TOD=NOPROMPT 

COM='S NET,,,C€LIST=01),SA=01' 
COM='S OCCFN,SA=01' 


JCL procedure to start MVS/OCCF, 


NPDA, and NCCF 


Member: OCCFEN 

//OCCFN PROC NAME=CBFDISP, Qi=NCCFR2,Q2=NPDAV2, 

//7*XCCFN PROC NAME=BNJLINTX, Q1=NCCFR2,Q2=NPDAV2, 

//*¥CCFN PROC NAME=DSIMNT, Q1=NCCFR2,Q2=NPDAV2, 

Jf RGN=4000K,SA=11, 

7 BFSZ=8K,SLSZ=200,0UT=L 

4/3571 EXEC PGM=&NAME, TIME=1440,REGION=&RGN,PARM=C&BFSZ, 
// DPRTY=(€15,10),PERFORM=13 

//STEPLIB DD DSN=&Q2..NPDALIB,DISP=SHR 

//SYSUDUMP DD DUMMY 

//SYSPRINT DD SYSOUT=&0UT 

//BNJLGPRI DD DSN=BNJLGPRI,DISP=OLD <=== N 
//BNJLGSEC DD DSN=BNJLGSEC, DISP=OLD <=== N 
//QCCFPDS DD DSN=SYS1.PROCLIB,DISP=SHR 

// DD DSN=SYS2.0CCFPDS,DISP=SHR 

17 DD DSN=SYS2.PROCLIB,DISP=SHR 

//7LINENETO DD UNIT=068 < 
//DUMPNETO DD SYSOUT=I < 

7/NSAM DD DSN=0Z.VSAM,DISP=SHR <== 
//DSICLD DD DSN=&Q1..CLISTLIB,DISP=SHR <= NCCF 
/J/DSIPARM DD DSN=SA&SA..DSIPARM, DISP=SHR | 
//DSIVTAM DD DSN=SYS1.VTAMLST,DISP=SHR 

//DSIPRE DD DSN=SA&SA..DSIPRF,DISP=SHR 

//DSIIRDR DD SYSOUT=CA,INTRDR) | 

Y/DSILOGP DD DSN=NCCFLOG.SA1LIP,DISP=SHR, AMP=AMORG 
/7DSILOGS DD DSN=NCCFLOG.SA115, DISP=SHR, AMP=AMORG 


&SLSZ), 


PDA data 
PDA data 


Cees 


CLISTs 


MVS/OCCF 


NPDA 
NCCF 


base 
base 
OCCF 


=== OCCF ROCF support 
=== OCCF ROCF support 
INFO/System data base 
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MVS/OCCF start-up parameters 


Member: OCCFPARM 
DESIG=% | 00010072 


ATTACH=NCCF 00020072 
MSGBUF=500 - -_ | 00030068 
CPROC=4 : 00040057 
CMDAUTH=PM : : | 00060056 


MATAB=11 <== = suffix for the name of the message action table 


OCCFPARM is a member of the OCCF partitioned data set which is defined by 
the DD statement named OCCFPDS in the JCL procedure used to start OCCF. 


MVS/7OCCF Message Action Table 


Member: MATABO1 


IX ROUTE | 00010000 
SH* ROUTE | 00020000 
TEF005Q REPLY=U 00030000 
RC=(1,2,3,4,5,6,7,8)9, 10, 1tst2; 13; 14, 15,16) 00040000 
IEC12341 REPLY= U | | 00050000 
IEFI234I REPLY=YES | 7 00060000 
TEF1234 REPLY=NO | 00070000 
IGF500D REPLY=NO 7 | | 00080000 
IKTOO03D REPLY=RETRY | - 4 00081000 
TKT012D REPLY=U | 00082000 


DSI800A REPLY=RETRY | | | 00090000 


LG OCCF Message Action Table is is a member of the OCCF partitioned data 
set. 


— NCCF initial CLISTS 


“&CONTROL ERR 
: NCCF initial CLIST for subarea 01. 
am 


&WRITE X------------------------------------- == -- $= - == === - 
&WRITE | 

&WRITE 
—&WRITE 
ZWRITE 
&WRITE 
RWRITE 
RWRITE 
RWRITE : oe | 
RWRITE X-------------- 9-2 = 
F NET,NOTNSTAT 

F NET, IOPD, IOINT=25 

MVS %AUTO 01 | 

EVERY 1,PPT,ID=NPDAIN,NPDAINT 

EVERY 30, PPT, ID= SYSMON , MONITOR 


OCCF Initial CLIST %AUTO 01 started via MVS. command 
NPDA filters are set 

OCCF CLIST “%SYSMON will be invoked every hour and 

can be cancelled by: PURGE TIMER=SYSMON,OP=PPT 


* ————-— ———— x 
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Member: NPDAINT 


&CONTROL ERR 

NPDASRF 

PURGE TIMER=NPDAIN,OP=PPT 
& EXIT 


Member: NPDASRF 


&CONTROL ERR 
&WRITE NPDA FILTERS INITIALIZED. 


NPDA SRF AREC PASS T CUST 
NPDA SRF AREC PASS T IMR 
NPDA SRF AREC PASS T PERF 
NPDA SRF AREC PASS T PERM 
NPDA SRF AREC PASS T PROC 
NPDA SRF AREC PASS T TEMP 
NPDA SRF AREC PASS T SNA 
NPDA SRF AREC PASS T USER 
NPDA SRF AREC PASS TREF CPU 


&EXIT 


Initialization of NPDA filters is deferred for one minute because NPDA is 
not up by the time the 'NCCF initial CLIST' is executed. 


MVS/OCCF CLIST to facilitate system activation 


Member: AUTO 


&DEF OPT TE 11 
&IF &1 NE ? &GOTO -GO 
&WRITE SYSTEM START-UP PROCEDURE 


-~HELP 

&WRITE FORMAT: “AUTO NN WHERE NN IS SUBAREA, DEFAULT = 11. 
& EXIT 

-GO 


&IF &1 EQ 11 &GOTO -CENT1 
&IF &1 EQ 01 &GOTO -SUBO1 
&IF &1 EQ 21 &GOTO -SUB21 
WRITE WRONG SUBAREA SPECIFIED 
&GOTO -HELP 

-~CENI1 

&WRITE S TSO 

> TSO 

&WRITE S NPA 

2 NPA 

&WRITE S HCF 

39 HCF 

ZACT N1401 

ZACT NOG21 

ZACT N2403 

ZACT LOCI1I3 

“ZACT LOC117 

&GOTO -FINAL 

-~SUBOL 

&WRITE S$ CICS 

9 CICS 

&éWRITE S TSO 

S TS0 

&WAIT 99 

V 370-37F,0NLINE 

ZACT NO421 

“zACT LOCO12 
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&GOTO -FINAL 

~SUB21 

&WRITE S APPL24 

S APPL24 

&WRITE S TSO 

S TSO 

ZACT N2403 

-FINAL 

&WRITE V NET,ACT,ID=M&1 

V NET,ACT, ID=M&1 

“ZSTARTNJE &1 

KURI TE 4 56 6 KE EK EE DEE DE EE EE IE HK DE DE DE DE DE DE DE DE DE DE DE DE IE DE DE HE IE DEE DE IE DE HE DE DE DE DEK DE IE DE HE DE IEE EE EE EEK 
&WRITE * MVSOCCF: AUTOMATIC SYSTEM INITIALIZATION IS NOW COMPLETE * 
&WRITE * FOR THE FOLLOWING DATE AND TIME x 


SWRITE 2 2.t 2.0.0.0.0.0.0.0.2.0,.0.0,.0,0.0.0,.0,0.0,0,.0.0,.0,9,.0,0,0,0.0,9.0,0,.0,0,.0,.0.0,5,0,. 0.0.0, 0,0,0,0,.0,0, 0.0.0. 0.0,5,0,04) 
&EXIT 


MVS/OCCF CLIST to start NJE 


Member: STARTNJE 


&DEF OPT TN 01 
&IF &1 NE ? &GOTO -GO 
&WRITE STARTNJE PROCEDURE 
&WRITE FORMAT ZSTARTNJE NODE : WHERE NODE EQUALS LOCAL SA NUMBER 
SWRITE USE TO CONNECT MVS TO MVS CNJE) VIA MSNF 
& EXIT 
-GO0° 
S$SLGN1 
 $SLNE1 
SSLNE2 
SSLNE3 

etc. 
&IF &1 EQ 11 &GOTO -SAl11 
&IF &1 EQ 01 &GOTO -SAO1 
SIF &1 EQ 21 &GOTO -SA21 
& EXIT 
-SAl1 
SSLNE8 
SSLNE9 
&WRITE $S5N,A=RDPDLIMVS 
SSN,A=RDPDIMVS 
RWRITE SSN,A=REMJESO1 
SSN,A=REMJESO1 
&WRITE NJE SHOULD BE UP 
& EXIT 
-SA01 
&WRITE $SN,A=RDPD3MVS 
SSN,A= RDPD3MVS 
RWRITE NJE SHOULD BE UP 
&EXIT 
-SA21 
&WRITE $SN,A=RDPD3MVS 
SSN,A=RDPD3MVS 
&WRITE NJE SHOULD BE UP 
& EXIT 
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NCCF CLIST to establish NCCF-NCCF and NCCF-OCCF sessions 


&CONTROL ERR 
&IF .&1 EQ .? &THEN &GOTO -TELL 


&GOTO -GO 

=TELL 

&BEGWRITE -END 

X----------- - --- - - - - - = - = $$ = 5 - = = = - = - % 


| Enter CENTRAL to start NCCF and OCCF sessions for | 
| CENTRAL OPERATION. | 
| Enter GO when message DSI809A appears. | 
| Enter GO SKIP if error message appears. | 


éWRITE OCCF *%QLOGON 
OCCF *QLOGON 
&WRITE START DOMAIN=NCFO1 
START DOMAIN=NCFO1 
géWRITE Enter GO when message DSI809A appears. 
&WRITE Enter GO SKIP if error message appears. 
&PAUSE VARS &A 
&IF .&A EQ .SKIP &THEN &GOTO -NCF21 
&WRITE NCFO1 NETOP,NETOP 
NCFO01 NETOP,NETOP 
éWRITE Enter GO when NCCF session started. 
&WRITE Enter GO SKIP if error message appears. 
&PAUSE VARS &A 
&IF .&A EQ .SKIP &THEN &GOTO -NCF21 
&WRITE OCFOL %ZQLOGON 
OCFO1 *QLOGON 
-NCF2] 
&WRITE START DOMAIN=NCF21 
START DOMAIN=NCF2l 
&WRITE Enter GO when message DSI809A appears. 
&WRITE Enter GO SKIP if error message appears. 
&PAUSE VARS &A 
&IF .&A EQ .SKIP &THEN &GOTO -NCF31 
&WRITE NCF21 NETOP,NETOP 
NCF21 NETOP,NETOP 
&WRITE Enter GO when NCCF session started. 
&WRITE Enter GO SKIP if error message appears. 
&PAUSE VARS &A 
IF .&A EQ .SKIP &THEN &GOTO -NCF31 
&WRITE OCF21 %QLOGON 
OCF21 X%QLOGON 
-NCF31 
etc. | 
&WRITE AUTO NCCF and OCCF LOGON complete. 
& EXIT 


Member:  NCFO1 


&CONTROL ERR 
ROUTE NCFO1 &PARMSTR 


Member: OQCFO1 
&CONTROL ERR 


ROUTE NCFO01,0CCF &PARMSTR 
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APPENDIX C.  NCCF COMMAND PROCESSOR: MVS 


The NCCF 'MVS* command processor is one method by which an operator or the 
NCCF PPT can issue any commands from NCCF stations to system internal 
reader. The reason why ‘'MVS' command processor uses internal reader 
instead of SVC 34, is because authorization of NCCF is required to use SVC 
34. A sample of '"MVS' is included. It is designed that 1t will pass the 
command to a program called SVC34 Which in turn is authorized to issue 
almost all MVS, JES2, OCCF, and SOF commands. The source and JCL for 
$VC34 follows the source for the 'MVS' command processor. 


To i implement this 'MVS" command processor, the following steps are 
required: 


(1) Assemble and link edit MVSCMD source code into the NCCF 
program library(default: SYS1.LINKLIB). 

(2) Define a CMDMDL statement for the 'MVS' command processor 
in the DSICMD member of the NCCF defintion: 


===> MVS CMDMDL MOD=MVSCMD, TYPE=R,CTL=N 
(3) Restart NCCF 
(4) Assemble and link edit 'SVC34" sample program. e 


NCCF ‘'MVS* Command Processor (SVC34 interface) 


* NCCF "MVS" COMMAND PROCESSOR (SVC34 INTERFACE). 

* THE DATA DEFINED AT THE LABEL JOBCARD SHOULD BE CHANGED TO 

* REFLECT THE SYSTEM REQUIRED JOBCARD. 

* AN INTERNAL READER STATEMENT IS REQUIRED IN THE NCCF PROCEDURE 
* TO SUPPORT THIS COMMAND. 

MVSCMD CSECT 


RO EQU 0 
Rl EQU 1 
R2 EQU 2 
R3 EQU 3 
R4 EQU 4 
R5 EQU 5 
R6 EQU 6 
R7 EQU 7 
R8 EQU 8 
RY EQU 4 
R10 EQU 10 
Ril EQU 11 
Rl2 EQU 12 
R13 EQU 13 
R14 EQU 14 
R15 EQU 15 


PRINT NOGEN 

DSICBS DSICBH, 
DSICWB, 
DSISWB, x 
DSIMVT, 
DSITIB, 
DSITVB, 
DSIPDB, 
DSISCE, 

- PRINT=NO 
PRINT GEN 
MVSCMD  CSECT 

SAVE (14,12) 

LR —-R12,R15 

USING MVSCMD,R12 

USING DSICWB,R1 

LA  R10,CWBSAVEA 

ST R10,8(R13) 

ST R13,4(R10) 

LR  ——- R13,R10 

USING CWBSAVEA,R13 


MK MK KK KOK OX 
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DROP Rl 


L R11,CWBTIB 
USING DSITIB,R11 
L R&8,TIBTVB 
USING DSITVB,R8 
L R10,TVBMVT 
USING DSIMVT,R10 
L R9,CWBPDB 
USING DSIPDB,R9 
DROP R8& 


MVI WORKAREA,X'00' 

MVC WORKAREA+1(255), WORKAREA 
MVI CMDAREA,X'40' 

MVC CMDAREAt1079),CMDAREA 


L R4,CWBBUF 
LH R5,0CR4) GET MESSAGE LENGTH 
SH R5,CMDLNGTH TEST FOR INPUT LENGTH 
as BM LONGCMD INPUT TOO LONG 
CLI PDBNOENT+1,X'01" 
BE NOOSCMD NEEDS OS COMMAND AS PARM 
OPEN CINTRDR, COUTPUT)) 
L R6,CWBBUF 
AH R6,22(0R9) POINTS OPERAND PORTION 


LH R5,0CR4) 
SH R5,22CR9) 
AH R5,18CR9) LENGTH OF OPERAND 
oT R5,SETUP | 
MVI SETUP,X'40' 
L R7,SETUP 
* TESTS TO LIMIT SCOPE COULD BE DONE AT THIS POINT 
* CLI OCR6),C'S! 
% BE JES2CMD 
x CLI . OCR6),C's* 
as BE SOFCMD 
* CLI OCR6),C'R" 
* BE OCCFCMD 
OCCFCMD EQU x 
SOFCMD LA R9,78 
LA R&8,CMDAREA 
MVCL R8,R6 
PUT INTRDR, JOBCARD 
PUT INTRDR, EXECSOF 
x THE NEXT STATEMENT IS REQUIRED IF THE PROGRAM SVC34¢ IS NOT IN A 
* LIBRARY IN LINK LIST. THE STEPLIB MUST BE AUTHORIZED. 
PUT INTRDR,STEPLIB 
PUT INTRDR,UTICARD 
PUT INTRDR,OSCMD 
PUT INTRDR, ENDCARD 
CLOSE CINTRDR) 
LA R1,MSG001 
MVI RETCODE,X‘'00' 
B PUTMSG 
% 


LONGCMD EQU is 
LA R1,MSG001 
MVI RETCODE,X‘'08! 
B PUTMSG 
NOOSCMD EQU x 
LA R1,MSG002 
MVI RETCODE,X‘'08' 


B nee 
PUTMSG EQU 

MVC MSGAREA(50), OCR1) 

LA R2,BUFFER 

USING BUFHDR,R2 

LA R1,50 

OTH R1,HDRMLENG 

BAL R14,PUTBUFF 
RETURN EQU * 

OLR R15,R15 

Tc R15,RETCODE 


L R13,4CR13) 
LM RO,R12,20(R13) 


L R1i4,12(€R13) 
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BR R14 


x 
PUTBUFF EQU x » 
| R14¢,SAVE14A 
CLI HDRTDISP+1,X'00' 
BNE HALFDONE 
LA RO,BUFHDRND~BUFHDR 
STH RO,HDRTDISP 
MVC HDRDOMID(8) ,MVTCURAN 
MVI HDRMTYPE,C'U' 
LA RO,120 
STH RO,HDRBLENG 
HALFDONE EQU x 
BAL R14¢,GETTIME 
ST R1,HDRTSTMP 
L R1,CWBSWB 
DSIPSS SWB = (R1),TYPE=OUTPUT,BFR=(R2) 
L R14, SAVELGA 


BR R14 
% 
GETTIME EQU x 
oT R14,SAVE14B 
DSIDATIM AREA=PACKAREA, FORMAT=BINARY 
L R1,PACKAREA+4 
L R14,SAVE14B 
BR R14 


CMDLNGTH DC = X*'0021' 

MSG001 DC CL50"MVSCMD COMMAND ISSUED VIA INTRDR? 

MSG002 DC CL50'MVSCMD INPUT IS REQUIRED! 

JOBCARD DC CL80'//DSIDUNMY JOB MSGCLASS=S,CLASS=I ' 

EXECSOF DC CL80*// EXEC PGM=SVC34 ' 

STEPLIB DC CL80'//STEPLIB DD DSN=CNM.DEMO.LINKLIB,DISP=SHR! 

UTICARD DC CL80'//SYSUT1 DD DATA 

ENDCARD DC CL80'/x | ' 

PREFIX DC CL3'/7 ' 

PREJES2 DC CL2'7x? | 

INTRDR DCB  DSORG=PS,MACRF=(PM),LRECL=80,BLKSIZE=80,RECFM=F, c 
DDNAME=DSIIRDR 


% 
DSICWB DSECT 

ORG CWBADATD 
WORKAREA DS OCL256 
COMMAND DS OCL32 
CMDLNG DS H 
CMDFLG DS H 
OSCMD DS OCL80 
CMDAREA DS CL80 


DS CL8 

DS CL8 
PACKAREA DS D 
SAVE14A DS F 
SAVE14B DS F 
SETUP DS F 
RETCODE DS C 

DS CL3 
BUFFER DS 


OF 
DS XL CBUFHDRND-BUFHDR ) 
MSGAREA DS OCL96 
LABEL1 EQU x 
DS XL¢€256-CLABEL1-WORKAREA) ) 
% 


*S$VC34' Sample Program Source 


This load module must be placed in an authorized library. 
47ASM EXEC ASMFCL | 

“/SYSIN DD x | 

SVC34 TITLE "SVC 34 - COMMAND ISSUE ROUTINE | . , MxM 
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% PRINT NOGEN 
* this program must be placed in an wither ese library. 


SVC34 CSECT — ; 
STM) = -R14,R12,12(R13) SAVE REGISTERS | 
LR R11,R15 LOAD ENTRY ADDRESS TO BASE REGISTER | 
USING SVC34,R11 ESTABLISH ADDRESSA BILITY | 
B AROUNDID ; AROUND MODULE ID 

| 2% DEC CL8'SVC34. MODULE ID 

AROUNDID DS 0H 
ST R13,SAVE+4 x 
LR R10,R13 LINKAGE 
LA = R13,SAVE CONVENTION 
ST. —- R13,8(R10) x 


MODESET KEY=ZERO,MODE=SUP 
OPEN CSYSUT1,CINPUT)) 


READ GET SYSUT1,INAREA READ COMMAND 
MVC  $CMD,INAREA MOVE COMMAND TO BUFFER 
SR —s- RO, RO CLEAR FOR SVC 34 
LA R1, COMMAND POINT COMMAND AREA 
SVC 34 ISSUE COMMAND 
B READ READ NEXT COMMAND FROM SYSUT1 

EOF DS OH : END OF FILE ENTRY 
CLOSE (SYSUT1L) CLOSE FILES 
L R13,SAVE+4 | 
LM = R14,R12,12(R13). RESTORE REGISTERS 
XR  -R15,R15 SET RETURN CODE = 0 
BR seR14 EXIT 

x . 

RO EQU 0 

Ri EQU ol 

R2 EQU 2 

R3 EQU 3 

R4 EQU 4 

R5 EQU 5 

R6 EQU 6 

R7 EQU 7 

R8 EQU 8 

R9 EQU 9 

R10  EQU 10 

Rll EQU 11- 

R12 EQU 12 

R13 EQU 13 

R14 EQU 14 

R15 EQU «15 

% 
DS 0D 

SAVE DS 18F : SAVE AREA 

-INAREA DC CL80" ! COMMAND INPUT AREA 

COMMAND DC  AL2(32,0) LENGTH & FLAGS 

SCMD DC —- CL28" 

: | 
TITLE 'D C B --- SYSUT1, SYSUT2! 


SYSUT1 DCB DDNAME=SYSUT1,DSORG=PS,MACRF=GM, EODAD=EOF, 
| | RECFM=F,BLKSIZE=80,LRECL=80 
/® | 
END 
/* 


//LKED.SYSLMOD DD DSN=SYS2.LINKLIB,DISP= SHR 
//LKED.SYSIN DD x 

ENTRY SVC34 

SETCODE ACC1) 

NAME SVC34(R) 
/¥ 
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Sample procedure to test the program SVC34 


/7/DSTIDUMMY JOB MSGCLASS=5,CLASS=I 
77 EXEC PGM=SVC34 

77SYSPRINT DD SYSOUT=5 

//SYSUT1 DD DATA 

ZAUTO 11 

7% 
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APPENDIX D. WORLD TRADE SYSTEM CENTER TECHNICAL PAPERS 


NETWORK MANAGEMENT 


GG24-1539-0 
Communication Network ManagementZ 
Managing Interconnected Systems 


The aim of this paper was to examine central site management 

of distributed processing systems. Situations were examined that 
included either a OS/MVS system or a DOS/VSE system as central host. 
The requirements for controlling these 

situations from a central 

site fell broadly into three areas. These were: 

Network Operation, 

Program Maintenance and Batch Data Transfer, and 

Problem Determination. 


GG24-1540-0 
Communication Network Management/ 
NCCF Terminal Access Feature 


This document contains an overview of the 
Terminal Access Facility of NCCF. The document was produced as a 
by- product of an early testing of the product and provides useful 
scenarios on how the product can be used. 


GG24-1546-0 
Communication Network Management/ 
Using Information/Management 


The intent of this paper is to ease the initial use of some functions 
of Information/Management CINFO/MGMT) and its interface to NPDA. 


It presents examples on defining a network containing multiple systems. 


GG24-1554-0 
Communication Network ManagementZ 
Customizing NCCF 


This document is intended to supplement the NCCF Customization 
Manual (€$C027-0433) with further hints, comments and examples on 
writing CLISTs, Command Processors and User Exits for NCCF. 

It should be read in conjunction with the NCCF Customization Manual. 


INSTALLATION SUPPORT 


GG24-1547-0 
Advanced Communications 
Function Primer 


This document provides overviews on some of the SNA products and 


expands on the examples in the ACF Product Installation Guide 
(GG24-1557). 
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G624-1557-0 
Advanced Communications Function 
Products Installation Guide 


The purpose of this guide is to provide 

information that may help in installing SNA products 

on either a DOS/VSE or OS/VS operating system using MVS. 

This guide supports ACF/VTAM V1IR3 and V2R1. 

It supports ACF/NCP V1R3. 

The samples in this guide will support the following products: 
IMS/VS, CICS/VS, TSO, JES2(MVS), 

ACF/VTAM, 

ACF/NCP/VS, NCCF, NPDA, VSE, POWER, FTP, JEP, and VSE/OCCF. 


G624-1509-0 
SNA Product Installation Guide/ 
ACF/VTAM Release 2 


The purpose of this guide is to provide 

information that may help in installing SNA products 

on either a DOS/VSE or OS/VS operating system using MVS. 

This guide supports ACF/VTAM V1IR2 and ACF/NCP V1IR2 and VIR3. 
The samples in this guide will support the following products: 
IMS/VS, CICS/VS, TSO, JES2(MVS), 

ACF/VTAM, 

ACF/NCP/VS, NCCF, and NPDA. 


GG24-1519-0 

Small Communications Systems 
Installation Primer 

IBM G331/ACF/VTAME 


This publication contains basic information needed to assist the 
user in adding the telecommunications capability to an IBM 4331 
DOS/VSE System. It is specifically directed to the installation of 
IBM 3270, ACF/VTAME, and CICS/VS systems. 


~6hmGG24-1552-0 
Small Communications Systems 
Installation Primer 
VSE System IPO/E & IBM 3705-80 


The purpose of this guide is to assist the user in the 
installation of a telecommunications system based on 

“- IBM Systems Network Architecture (SNA) 

- An IBM 4300 Processor 

VSE System IPO/Extended 

CICS/VS 

An IBM 3705-80 Communication Controller 

IBM 3270 Information Display System 


PROBLEM DETERMINATION 


GG24-1514-0 
SNA Problem Determination Guide/ 
ACF R3 Volume 1 


This paper is part of a two volume series dealing with 
system problem determination in a ACF/VTAM environment. It 
ae and illustrates problem determination techniques 
an ools. 


GG624-1523-0 

Availability: May 1982 

SNA Problem Determination Guide/ 
ACF R3 Volume 2 
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ABEND 
ACB 
ACF/NCP 


ACF/TCAM 
ACF/VTAM 


NCCF 


PA key 
PARMLIB 
PDS 
PF key 
PU 


RACF 
RMFMON 
ROCF 


APPENDIX E. ACRONYMS AND ABBREVIATIONS 


Abnormal End of a program 

Access Control Block CVTAM) 

Advanced Communications Function for 

Network Control Program 

Advanced Communications Function for the 
Telecommunications Access Method 

Advanced Communications Function for the 
Virtual Telecommunications Access Method 
Application identification (CVTAM definitions) 
Binary Synchronous Communication 

Basic Telecommunications Access Method 
Cross-Domain Resource Manager 

Cross-Domain Resource 

Customer Information Control System / Virtual Storage 
Command List 

Clear Link Pack Area (MVS) 

Communication Management Configuration 
Communication Network Management 

Central Processing Unit 

Channel to Channel Adapter 

Direct Access Storage Device 

Data Definition (MVS JCL) 

Disk Operating System / Virtual Storage Extended 
IBM 8100 Distributed Processing Control Executive 
IBM 8100 Distributed Processing Programming Executive 
IBM 3705 Emulation Program 

Field Developed Program 

Generalized Trace Facility 

IBM 8100 Host Command Facility . 
Identification 

Initial Micro-program Load 

Information Management System / Virtual Storage 
Information System 

Initial. Program Load 

Job Control Language 

Job Entry Subsystem (JES2 or JES3) 

Logical Unit (SNA) 

Mass Storage System 

Multiple Virtual Storage (OS/VS2) 

MVS Operator Communications Control Facility 
Network Communications Control Facility 
ACF/NCP 

Network Performance Analyzer 

Network Problem Determination Application 
MVS/OCCF 

Operating System | 

Program Action key (3270) 

Parameter library (MVS) 

Partitioned Data Set 

Program Function key (3270) 

Physical Unit (SNA) 


Resource Access Control Facility 


Resource Measurement Facility Monitor 
Remote Operator Control Facility 

IBM 3705 Remote Program Loader 
Synchronous Data Link Control 

System Network Architecture 

Secondary Operator Facility 

System Services Control Point 
Supervisor Call (05) 

Terminal Access Facility 

ACF/TCAM 

Terminal Control Table (CICS) 
Transmission Group 

Time Sharing Option 

ACF/VTAM 

Write To Operator (MVS console support) 
Write To Operator and request Reply (MVS console support) 
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COMMUNICATION NETWORK MANAGEMENT OMEA 
CENTRAL SITE OPERATION Sachi 


Staples can cause problems with automated mail sorting equipment. 
Please use pressure sensitive or other gummed tape to seal this form. 


Note: 


— ee ee ee ee ee ee ee ee ee oe ce ee ee cee ee eee ome eee com cme ce ee ee ee ee ee ee ee es ee ee eee ee ee ee ee ee ee oe er ce oe ome cee am ame cee cme ae cow ceme cm cme comm ce cree eee coe cme cme ume comme cum ces eee eee eee ee we eee ee ee ee ee ees we ee 


You may use this form to communicate your comments about this publication, its organization, or 
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